← Back to Routella

Security and Compliance

Last updated: May 12, 2026

This page describes Routella's security and privacy practices in detail. It is referenced by our Privacy Policy and Data Processing Agreement. It is intended for merchants, their auditors, and platform partners (e.g. Shopify Built-for-Shopify reviewers).

Data Minimization and Purpose Limitation

We collect only the personal data we need to operate the delivery management service: merchant account data, end-customer order data (name, address, phone, email, order line items), driver contact info, and driver GPS location during active rounds. We do not collect government IDs, payment card numbers, or customer browsing history. We do not enrich personal data with third-party profiles. Each data category is mapped to exactly one purpose; the same data is not reused for marketing, ad targeting, or resale.

Consent and Customer Decisions

  • Routella sends transactional messages on the merchant's behalf (e.g. "your order is on its way"). These are not marketing messages and follow the merchant's configuration.
  • Customers can opt out by replying STOP, UNSUBSCRIBE, CANCEL, END, or QUIT to any Routella WhatsApp or SMS message. Opt-outs are stored per merchant in the WhatsAppOptOut collection and checked before every send. Customers can opt back in with START, SUBSCRIBE, or RESUME.
  • No data sale. Routella does not sell personal data. The "do not sell" decision is therefore honored by default for every customer.
  • Automated decisions. Route optimization and auto-dispatch are operational optimizations. They do not produce legal or similarly significant effects on individuals (GDPR Art. 22). Merchants can override any automated assignment manually.

Storage and Retention

Retention windows are enforced automatically by MongoDB TTL indexes and a daily retention cleanup cron at 04:00 UTC.

  • Driver GPS location: 24 hours
  • Error logs: 14 days
  • Cron run records, webhook delivery history: 90 days
  • Public tracking-page view logs: 90 days
  • Sign-in events: 180 days
  • Personal-data access audit log: 365 days
  • Customer notification history, order import history: 2 years
  • Orders, manual orders, completed rounds: 5 years
  • Merchant account data: kept while active. Deleted within 30 days of account closure. Legal/billing records may be kept up to 7 years where law requires.

Encryption

  • In transit: all endpoints use HTTPS with TLS 1.2 or later. Vercel terminates TLS and enforces HSTS. Every connection to a sub-processor (MongoDB Atlas, Shopify, Infobip, Resend, WAHA, geocoding APIs) is also TLS-protected.
  • At rest: MongoDB Atlas provides AES-256 encrypted storage by default. Backups inherit the same encryption.
  • Field-level encryption: integration credentials (Shopify access tokens, API keys, consumer secrets, OAuth tokens for the 20+ connected platforms) are additionally encrypted with AES-256-GCM per-field, with a separately-managed key (FIELD_ENCRYPTION_KEY), before being written to MongoDB. The application refuses to start in production if this key is missing.
  • Passwords: stored as bcrypt hashes with cost 12. They are never logged or sent in email.

Backups

MongoDB Atlas performs continuous backups with point-in-time restore. Backups are encrypted at rest with the same AES-256 standard as the live database. Restore procedures are tested. Retention of backups follows Atlas's default schedule and never exceeds the retention windows above.

Test and Production Separation

Production and non-production are fully isolated:

  • Separate MongoDB clusters with separate connection strings.
  • Separate Vercel projects with separate environment variables.
  • Production secrets are never present in development or preview environments.
  • Test data is synthetic; we never copy production personal data into staging.

Data Loss Prevention

  • Continuous backups with point-in-time restore, as above.
  • Idempotency keys on order import and webhook ingestion to prevent duplicate writes that could mask data loss.
  • Rate limiting on bulk-export and bulk-delete endpoints.
  • Soft-delete patterns on high-value records (orders, rounds) so accidental deletes can be reversed within the retention window.
  • Quarterly review of error logs and webhook-delivery failures to catch silent data drift.

Staff Access

  • Staff access to personal data is limited to engineers with a documented business need (production support, incident response). Access is reviewed at least every six months.
  • Each engineer authenticates with SSO and mandatory multi-factor authentication. No shared accounts.
  • Administrative operations are gated by a server-side ADMIN_USER_IDS allowlist enforced in the application code, independent of database-level access.
  • Confidentiality obligations are part of every engineer's engagement agreement and survive termination.

Authentication and Password Policy

  • Length: minimum 10 characters.
  • Composition: must contain at least one letter and one digit.
  • Common-password rejection: a denylist of well-known weak passwords (e.g. password, 123456789) is rejected at sign-up and password reset.
  • Reuse of identifiers: a password that matches or contains the user's email is rejected.
  • Hashing: bcrypt with cost factor 12.
  • Reset tokens: SHA-256-hashed before storage and time-limited.
  • Rate limiting: 5 reset attempts and 20 register attempts per 15 minutes per IP.
  • OTP option: merchants can sign in with a one-time email code instead of a password.

Access Logging

The following events are logged with timestamp, user ID, IP hash, and user agent:

  • Sign-in events — both successful and failed authentications (model: LoginEvent, retained 180 days).
  • Personal-data record reads — listing orders, listing drivers, searching customers, viewing manual orders (model: AccessLog, retained 365 days).
  • Admin actions — operations performed by users on the admin allowlist (model: AdminAction).
  • Public tracking-page views — when a customer opens their delivery tracking link, with the viewer's IP hashed before storage (model: TrackingView, retained 90 days).
  • Shopify GDPR webhooks — every customers/data_request, customers/redact, and shop/redact webhook is HMAC-verified and audit-logged with the topic, shop, customer identifiers, records touched, and outcome (model: GdprRequest, retained 7 years).

Shopify Compliance Webhooks

Routella subscribes to the three mandatory Shopify privacy webhooks at a single endpoint, /api/shopify/gdpr:

  • customers/data_request — within 30 days of receipt we collect every record Routella holds about the customer (orders, manual orders, notification history) and email it to the merchant so they can forward it to the data subject.
  • customers/redact — we immediately redact identifying fields (name, email, phone, address, building/floor/apartment, notes) across the Order and ManualOrder models and delete matching notification rows.
  • shop/redact — fires 48 hours after uninstall. We hard-delete the shop's ManualOrders, Orders, Rounds, Integration record, and ShopifyStore record.

Every webhook request is HMAC-verified (SHA-256, base64, against the raw body, using a constant-time comparison). Invalid HMAC returns HTTP 401. Successful requests return HTTP 200 within Shopify's 5-second timeout.

Security Incident Response

Routella follows a documented incident-response procedure:

  1. Detect. Sources include error logs, webhook health checks (every 15 minutes), the WhatsApp health-check cron, and reports to support@routella.app.
  2. Triage. Within 4 hours, the on-call engineer classifies severity, scope, and whether personal data is involved.
  3. Contain. Rotate affected credentials, revoke compromised sessions, and patch the vector.
  4. Notify. If a personal-data breach is confirmed, notify affected merchants within 72 hours of awareness with the nature, scope, likely consequences, and mitigations. Merchants notify their end customers and supervisory authority where required.
  5. Recover. Restore from backups if needed and verify integrity.
  6. Review. Post-incident review with a written report, root-cause analysis, and follow-up actions tracked to closure.

Reporting a Vulnerability

Please report suspected vulnerabilities to support@routella.app. We respond within two business days and do not pursue good-faith security researchers who follow responsible-disclosure norms.