AutoCard numbers never reach us
Your customers pay on Stripe's own hosted pages. Card numbers, expiry dates and security codes are typed on Stripe's domain, never on ours — there is no field anywhere in AutoDX that accepts one, and nothing resembling a card number is stored in our database. Subscription management runs through Stripe's billing portal for the same reason.
When Stripe tells us a payment succeeded, that message is checked against a signature before we act on it, using a constant-time comparison. A forged "payment received" from someone else cannot mark an invoice paid.
We never see your password
Sign-in is handled by a dedicated identity provider. There is no password column in our database — we could not leak your password because we do not have it.
Every request your browser makes carries a short-lived token, and our server checks that token with the identity provider instead of trusting what the browser claims about itself. An expired or altered token is refused. This matters more than it sounds: the common way a young application gets breached is trusting the client, and we do not.
One shop cannot see another shop's data
Every record — repair orders, customers, vehicles, invoices, inventory, technician hours — is tied to a shop, and every query is filtered by it. That is the boring part. The part worth telling you is that thirty of our test files exist specifically to prove it: they create two shops, then have one ask for the other's records and assert that it gets nothing back. Those tests run before every change ships.
A vehicle's history by VIN is the one thing shared across shops, and deliberately so — a car that was diagnosed once should not be a blank page at the next shop. What is shared is the technical record of the vehicle. Your customers, your pricing, your labor rates and your invoices are not.
Your data does not become our hostage
The most expensive part of leaving a shop management system is usually getting your own history out of it. So:
- A read-only API under your shop's own key, so you or anyone you hire can pull your repair orders, customers, estimates and payments into your own tools.
- CSV exports of invoices, payments and repair orders, straight from the cabinet.
- Published limits. Every API response carries its own rate limit in the headers, so nobody has to discover a cap by being cut off by it.
In the browser
The site and the API are HTTPS only. Every page is served with:
X-Frame-Options: DENYandContent-Security-Policy: frame-ancestors 'none'— AutoDX cannot be embedded in someone else's page, which is how clickjacking attacks trick a signed-in user into clicking something they cannot see.X-Content-Type-Options: nosniff— the browser will not guess a file's type and run it as something it is not.Referrer-Policy: strict-origin-when-cross-origin— your internal page addresses are not handed to third-party sites.
Abuse limits
Endpoints that anyone can reach without signing in are rate limited per client, and the limit is enforced on the real client address rather than one a caller can claim in a header. When a limit is hit the response says so plainly, with how long to wait.
What runs where
The website is served from Vercel's global network. The application server runs on Render in Oregon, USA. The database is managed PostgreSQL hosted on AWS in the United States. We do not run servers in an office or under anyone's desk.
How changes reach you
Over a thousand automated backend tests, plus browser tests that drive the real interface, run before a change is deployed. That is not a security control by itself, but it is the reason a fix for one shop does not quietly break billing for another — and in practice most damaging incidents in small software are accidents, not attackers.
Found a problem?
If you believe you have found a security issue, write to support@autodxpro.com with enough detail to reproduce it. We will confirm we received it, and we will not threaten anyone who reports a problem in good faith.
Last reviewed: 2026-08-14.