Your delivery data, kept apart and kept private.

Every request to the office app and its API is checked on the server: the signed-in person’s memberships decide which business they may act for, and the role they hold (owner, admin, dispatcher or driver) decides what they may do. Nothing in a request body can pick a business. Drivers see only their own routes.

Underneath, row-level security is enabled on every table and the database’s public API keys have no access to any of them. Only Porch Route’s own server, with its own credential, reads or writes your data.

Porch Route has four ways in, each scoped to as little as possible:

• API keys are shown once. After that Porch Route keeps only a SHA-256 hash and a short prefix, so a database copy never hands anyone a working key. Each key belongs to one business and can be revoked at any time.
• Webhooks are signed. Every request carries X-PorchRoute-Signature: sha256=…, an HMAC-SHA256 of the raw body keyed on your endpoint’s secret, plus event and delivery ids. You verify it in constant time; rotating the secret invalidates the old one immediately.
• Endpoints must be public HTTPS. Private, loopback and link-local addresses are refused, and the hostname is resolved and re-checked at send time so a DNS trick can’t point our server at an internal network.
• Nothing goes missing quietly. Failed deliveries retry with backoff for a day, reconciliation reports anything still owed, and the delivery log shows every attempt with a way to send one again.
• Writes are idempotent. An Idempotency-Key on order writes means a retried request never creates the same delivery twice.

Into private storage with no public address. The app, the customer’s tracking page and your webhooks receive signed links that expire — one hour for people viewing them, seven days for links sent to your systems — so a link that leaks stops working on its own. A tracking page shows only that stop’s own photo.

A driver link opens exactly one route: its stops, instructions and the actions a driver needs. It stops working two days after the route date, is replaced whenever it is reissued, and can be turned off from the route at any moment — the driver’s screen locks. It never reaches another route, the business’s settings or anything financial.

A tracking link opens one stop with a deliberately thin payload: the business’s name, the truck’s position only while the route is running, a progress timeline, that stop’s proof photo and a rating form. Never the full address, the customer’s phone number, other stops or the driver’s phone number. Tracking pages carry no analytics and are never indexed.

In transit: every connection — browser, driver phone, API and webhook — uses TLS; webhook endpoints must be HTTPS. At rest: the database and file storage are encrypted by our hosting providers’ defaults (see the subprocessors page for who they are). Credentials that could act as a login — API keys, invitation tokens — are stored only as hashes.

Every plane is rate-limited, sized well above what a person or integration does and low enough to stop a script: office API calls per user, integration calls per key, driver-link reads and GPS pings per link, tracking-page reads per link, invitations per network, and this site’s contact form (five an hour per network). Limits hold across server instances. Messaging has its own daily safety caps per business.

Being straight about the gaps matters more than a long list of badges:

• No SOC 2 report or ISO certification, and no third-party penetration test yet.
• No formal bug-bounty programme. Good-faith reports are welcome and answered (below).
• Database backups follow our hosting provider’s plan; a written recovery objective isn’t published yet.
• No uptime commitment or service-level agreement. The status page shows live checks (app, database, geocoder, map tiles, the jobs tick); it doesn’t yet keep a history.

When any of these changes, this page changes with it — the date at the top is real.

Use the contact page and choose “Report a security issue”. Include steps to reproduce, the account or URL involved and what you observed. We acknowledge reports, keep you informed while we fix the issue and credit you if you’d like. Please don’t access or change data that isn’t yours, and give us a reasonable time to fix a problem before publishing it. Support is answered Mon–Fri 8am–5pm Mountain; a security report sent outside those hours is read the next working morning.

Our data commitments to businesses are in the data processing addendum; how personal data is handled is in the privacy policy.