Security & architecture

Built to be checked, not just trusted

DispatchingIQ holds dispatch, billing and driver data for small fleets and dispatch companies. Here is how that data is protected and how the AI is kept on a leash — stated as facts you can hold us to.

Per-tenant data isolation, enforced by the database

Every organization’s operational data sits behind PostgreSQL row-level security. The app connects as a non-superuser role and runs each request inside a transaction pinned to your organization id, so the database itself filters out every other tenant’s rows. Even a forgotten filter in application code can’t return another company’s data — Postgres won’t hand it over.

Role-based access, including a read-only client login

Access is scoped by role: owner, admin, dispatcher, and a read-only carrier-viewer login for the client carriers a dispatch company serves. A carrier-restricted user only ever sees their own carrier’s loads, fleet, documents and ledger — every role check runs on the server, on every action.

Two-factor authentication

You can turn on authenticator-app two-factor authentication for your login. Once it’s enabled, a correct password alone never issues a session — the second factor is verified on the server before you’re signed in.

An append-only audit log on every change

Every change is written to an audit log in the same database transaction as the change itself: who did it — a person or the AI — what changed, and when. The application only appends audit entries; it has no code path that edits or deletes them.

AI acts only with your approval

The AI reads rate cons, drafts loads and counter-offers, and flags risks — but anything that touches money or booking is approve-first by design. A person approves before a load is created or an offer is sent, the model can’t raise its own permission level, and there is no auto-book or auto-send path in the product.

Secrets stay out of the code

API keys and other secrets are never stored in DIQ’s source code or written to logs. They’re supplied to the running application from Azure Key Vault, so credentials live in a managed secret store rather than the repository.

Stripe-hosted payments — card data never touches DIQ

Payments run through Stripe’s hosted checkout and billing portal. Card numbers are entered on Stripe’s own pages and never pass through or get stored by DIQ — we keep a Stripe customer reference, not your card.

We state what the product does — nothing it doesn’t

Everything above describes how DispatchingIQ works today and is verifiable in ourcodebase. We don’t advertise certifications or uptime guarantees we don’t hold; when that changes, this page will say so. You can export all of your organization’s records at any time, and request deletion from Settings.

See it in your own account

Create your account and check the autonomy controls and audit log for yourself.