How your company’s data is kept apart

Separation is enforced in the database

Every record that belongs to a company — deliveries, drivers, vehicles, positions, invoices — carries that company’s identity, and PostgreSQL row-level security policies restrict what a connection can read to the company it is acting for. The application sets that company per request; the database refuses rows outside it.

This matters because the common failure is the other way round: a screen that filters by company while the query underneath could return anything. One missed WHERE clause is then a cross-company leak. Here the filter is not in the query, so it cannot be forgotten.

Authorization is decided on the server, every time

What a person may do is recomputed by the API on each request from their membership and role in the company they are acting for. Hiding a button in the interface is not treated as a permission — the request behind the hidden button is refused on its own merits.

Roles are coarse on purpose: owner, administrator, dispatcher, finance, viewer, and the branch-scoped equivalents. A permission system nobody understands is one that gets granted around.

Sign-in

• Passwords are stored as Argon2id hashes, never recoverable, and are re-hashed automatically when we raise the cost parameters.
• Sessions use short-lived access tokens with rotating refresh tokens. If a refresh token is ever presented twice — the signature of a stolen one — every session for that account is revoked and the person is told why rather than being quietly signed out.
• Two-factor authentication is available to company accounts and mandatory for our own platform staff. No member of our team can reach the console without it.
• Sign-in, password reset and verification endpoints are rate limited per account and per address, and a wrong password takes the same time to fail as an unknown email so the two cannot be told apart.

The audit trail cannot be quietly edited

Administrative actions — approvals, role changes, device assignments, plan changes — are written to an append-only audit log. The log is periodically sealed: a batch of entries is hashed together with the previous seal’s digest, so the seals form a chain. Removing or altering an entry after the fact breaks every seal that follows it, which is detectable without having to trust the people who hold the database.

GPS devices belong to one company

A tracker is provisioned against a single company and its vehicle, and the change of ownership is recorded. A device cannot report into two companies, and the platform staff who provision it leave an audit entry when they do.

Registration is reviewed by a person

A new company cannot dispatch until our team has checked it. That review is as much a security control as a commercial one — it is what stops an anonymous account from appearing inside a marketplace that real couriers and real customers are using.

Backups and retention

The database is backed up on a schedule, restores are exercised rather than assumed, and each run records how far back it can recover to and how long the restore took. Retention floors are set per kind of record, so operational data is kept long enough to settle a dispute and no longer than it needs to be.

What we do not claim

We have not completed an external penetration test and we hold no security certifications. We are a new platform, and saying otherwise would be the first thing you could catch us on. If your organisation needs either before signing, tell us during registration and we will say honestly where we are.

Reporting something

If you believe you have found a vulnerability, please tell us before telling anyone else. Reach us through the contact page; we will confirm receipt, keep you informed while we fix it, and will not pursue anyone who reports a genuine issue in good faith and does not exploit it beyond what was needed to demonstrate it.