Built for the operations director who has to defend the decision.
Odomotive sits between your telematics and your shops. That’s a sensitive seat. Here’s exactly what we read, what we never read, where we keep it, and how it’s protected at every layer.
In transit and at rest, with credential-grade ciphers.
All traffic between your browser, our API, and our telematics polling workers runs over TLS 1.3. We do not accept connections below TLS 1.2; HTTP redirects to HTTPS at the edge.
Your telematics credentials — the Geotab username/password you connect on setup — are encrypted at rest with XChaCha20-Poly1305 using per-tenant keys. Database backups are encrypted with the same envelope. We never log credentials in plaintext, and they are never returned to the client after the initial connect.
Application secrets (Vapi keys, Supabase service-role tokens, Twilio keys) live in Vercel environment variables, scoped per environment, and are rotated on a quarterly cadence.
Row-level security, enforced at the database.
Every table that holds tenant data — vehicles, faults, alerts, calls, shops, users — carries a tenant_id column with a Postgres Row-Level Security policy. The active tenant is resolved from the authenticated session via current_tenant_id(); queries that don’t match return zero rows.
This means even a bug in our application code can’t cross fleets. The isolation is enforced one layer below us, at the Postgres engine. Service-role queries used by background workers (poller, voice AI) take an explicit tenant_id argument and assert it before any read or write.
Your fleet’s data is never co-mingled with another fleet’s. We can prove this: ask us for our tenant-isolation test suite output during your security review.
Read-only. Maintenance-only. That’s the whole list.
We connect to your Geotab account using a read-only credential. Today we don’t write back to your telematics provider, push commands to vehicles, or modify driver assignments or vehicle records. If we ever introduce write actions (for example, recording a service event back to Geotab), it will be opt-in per tenant with an explicit consent screen and an audit log on this page.
From the read scope, we pull only what maintenance work requires: vehicle list, fault codes (DTCs and freeze frames), odometer, engine hours, and vehicle position. Position reads are event-triggered— we only read location briefly around shop appointments you’ve approved (to auto-confirm arrival and departure). Outside scheduled appointment windows, we ignore it.
We do not pull or store: continuous GPS tracking, route history, trip records, driver hours / HOS data, speeding events, harsh-braking events, fuel transactions, or dashcam footage. If you audit our telematics queries, you will not find these endpoints anywhere in our code.
One narrow exception worth naming.If you opt in to driver‑contextual alerts (so “Trevor’s truck threw P0420” reaches the right phone), we read the active driver‑to‑vehicle assignment for that alert window only. That feature is off by default; turn it off any time. Outside that, no driver PII is fetched or stored.
When you disconnect, we’re gone in 30 days.
Cancel your account or disconnect your telematics from the dashboard. We revoke your access tokens within seconds and stop polling immediately.
Your fleet’s historical data — faults, alerts, call logs, shop relationships — is retained for 30 days in case you reconnect or need a one-time export, then permanently deleted from primary storage. Backups age out within 90 days.
You can request earlier deletion at any time: justin@odomotive.com. We process those within 5 business days and send you a deletion confirmation.
Where we are, where we’re going.
- SOC 2 Type I — targeted Q3 2026 (roadmap)
- SOC 2 Type II — targeted end of 2026 (roadmap)
- GDPR & CCPA-friendly architecture — right-to-deletion supported today; DPA available on request
- Annual third-party penetration test — first engagement scheduled before any Fortune-500 fleet onboards
We’d rather show you the work than print a logo we haven’t earned. If you’re evaluating us against an enterprise security checklist and need our current control posture in writing, email justin@odomotive.com.
Three vendors. All audited. All publicly listed.
Supabase— managed Postgres, authentication, file storage. Our primary data plane. SOC 2 Type II. supabase.com/security
Vapi— voice AI provider that powers Odo’s outbound calls. They process the call audio; we send them the script and receive the transcript. vapi.ai/privacy
Vercel— application hosting, edge network, environment variable storage. SOC 2 Type II. vercel.com/legal/privacy-policy
When we add a subprocessor that touches tenant data, we update this list before we ship. If you want change notifications, email justin@odomotive.com and we’ll add you to the list.
Found something? Tell us. We’ll credit you.
We don’t run a public bug-bounty program yet, but we treat security reports with the seriousness they deserve. If you find a vulnerability in Odomotive, email justin@odomotive.com with reproduction steps and your preferred handle.
Our commitments to you: acknowledgment within 24 hours, fix-or-mitigation timeline within 5 business days, public credit on this page if you want it, and zero legal action against good-faith research.
Please don’t test against tenant data that isn’t yours, don’t run destructive load tests, and don’t share findings publicly until we’ve shipped a fix. Standard rules.
We’d rather answer your hardest question now than ship a vendor questionnaire later.
Email justin@odomotive.com with your security review checklist. We respond within one business day.