For developers

Security model

How Renaro keeps each company's data separate, who can sign in and how, what gets audited, and how personal data is masked and deleted.

Updated

Tenant isolation

Every business record belongs to one organization. Application code filters every query by the organization from the authenticated request, and PostgreSQL row-level security enforces the same boundary underneath: each transaction sets app.current_org_id with set_config(..., true) (the transaction-local equivalent of SET LOCAL), and table policies compare against it. A query that forgot its filter still cannot read another company's rows.

Authentication

WorkOS is the only identity provider. There are three ways in, and all of them resolve to the same request context before any handler runs.

  • Operator dashboard: WorkOS AuthKit session, sent as a session cookie or bearer token. WorkOS enforces MFA at sign-in.
  • Driver and passenger apps: OAuth 2.0 with PKCE, exchanged for bearer tokens.
  • Integrations: X-API-Key. Keys are stored as SHA-256 hashes, belong to one organization, carry explicit scopes, and are revoked individually. The Public API page covers keys in detail.

Roles, capabilities and step-up

Inside an organization, access is granted by role (Owner, Admin, Finance, Dispatch, User, or a custom role) and the capabilities it expands to. Routes check capabilities before doing any work. Sensitive administrative writes, including creating or revoking API keys and changing team roles, also require a WorkOS MFA sign-in within the last eight hours, and refuse API keys and impersonated sessions outright.

Audit records

Writes are recorded in an audit log with the actor, their role, the organization, the request id, IP address and user agent. Access to sensitive material, such as message history, signatures, report exports and payment requests, is recorded on read as well. Membership and capability changes are audited as membership.updated.

Phone masking

When a driver is assigned, Renaro opens a masked calling and texting session through Twilio Proxy so the driver and passenger reach each other without seeing real numbers. The session closes when the trip completes.

Live location data

The driver app records a GPS fix every 5 seconds on a trip and every 30 seconds when idle, and uploads positions over HTTPS in batches (every 30 seconds or 50 points), buffering them offline through dead spots. On receipt the API writes positions to Redis and fans them out over WebSocket to dashboard users whose role includes GPS, fleet or dispatch access; a worker persists them to PostgreSQL every 30 seconds. Dashboard clients reconnect with exponential backoff from one to 30 seconds and refetch state after reconnecting. The stored location history is never interpolated.

Deletion and retention

Records are soft-deleted, never removed in place. A confirmed account deletion is scheduled 30 days out and can be cancelled during that window; the organization is frozen immediately. Active trips, unpaid payouts or open payments block deletion, and retention or legal holds pause it. When the window closes, a worker anonymizes personal data, marks records deleted, and cleans up stored files, cache entries and provider records.