Security
Built for many clients under one roof
A 3PL holds other people's inventory and other people's customers. ShipFlow is designed so that each client's data is fenced off at the database, every action is attributable, and access ends the moment it should.
Authentication and access
- Roles and permissions. Warehouse staff and client users each get a role with an explicit permission set; every API route declares the permission it requires, and a boot-time check refuses to start if a route is left unguarded.
- Client portal entitlements. What a client's users can see is switched on per company by the warehouse, and further limited by the user's role.
- Session revocation. Deactivating a user, changing their password or changing their role invalidates their existing sessions immediately, not at expiry.
- Password recovery uses single-use, time-limited links; login attempts are rate-limited.
- API keys for client systems are scoped per client and per capability, shown once, stored hashed, and revocable at any time.
Per-client isolation
Every table that holds client data carries the owning tenant, and row-level security in the database enforces the boundary on every query. A client's portal users only ever reach their own company's rows; warehouse users are fenced to their warehouse. Integrations run per client with their own credentials.
Encryption
- In transit: TLS on every connection to the dashboard, the portal, the API and between our services and hosting providers.
- At rest: the database and file storage are encrypted by the hosting providers; integration credentials (store tokens, marketplace secrets, SFTP passwords) are additionally encrypted by ShipFlow with AES-256-GCM under a key that lives only in the server environment.
Hosting
The application runs on Railway, the database on Neon and the web front ends on Netlify, all in United States regions, each with their own SOC 2 programmes. Documents and photos are stored in Amazon S3 with server-generated keys and time-limited download links.
Audit logging
Administrative and data-changing actions (user changes, permission changes, integration changes, overrides, redactions) are written to an audit log with who, what, before and after, and from where. Integration runs keep their own log, including what a connected channel sent when a request could not be processed.
Development practice
Changes ship through automated verification suites that exercise the API against a local database, including isolation checks that assert one client cannot read another's rows. Dependencies are reviewed for known vulnerabilities, and secrets are kept in the hosting environment, never in the repository.
Responsible disclosure
If you believe you have found a security issue, email support@3pltechflow.com with "Security report" in the subject. We acknowledge reports within two business days, keep you informed while we fix, and do not pursue good-faith researchers who respect client data and give us reasonable time to remediate.