Trust

Security

How we protect your account, your keys, your provider credentials and your money.

Last updated 8 October 2026

Controls

Key hashing

API keys are stored only as hashes with a short public prefix. The secret is displayed once at creation and can never be recovered — only rotated.

Credential encryption

Upstream provider credentials are encrypted at rest with a key derived from your deployment's ENCRYPTION_KEY, and are never returned by any API.

Password hashing

Passwords are hashed with a memory-hard algorithm and are never logged or returned. Session tokens are stored as hashes.

CSRF hardening

Cookie-authenticated mutations enforce an Origin allow-list server-side. API-key requests, which are not cookie-based, are exempt by design.

Webhook verification

Payment webhooks are rejected unless the HMAC signature verifies, and each event id is recorded so a replayed delivery cannot double-credit a wallet.

Idempotent money

Wallet movements are append-only ledger entries guarded by idempotency keys, so retries cannot create duplicate credits or debits.

Rate limiting

Registration, sign-in and checkout are rate-limited per IP and per user to blunt credential stuffing and card-testing.

Request tracing

Every request carries an x-request-id that appears in logs and in error responses, so an issue can be traced end-to-end.

Audit logging

Security-relevant actions — sign-in, key creation, rotation, revocation, admin changes — are written to an audit log.

Least privilege

Administrative routes require an admin or support role, and support accounts cannot perform destructive billing changes.

Your responsibilities

  • Keep API keys out of client-side code, public repositories and logs.
  • Use a separate key per environment or per integration so a leak can be revoked narrowly.
  • Set an expiry and a spending limit on keys that do not need to be permanent.
  • Rotate a key immediately if you suspect it has been exposed — rotation invalidates the old secret at once.
  • Use a strong, unique password and keep your account email secure.

Data handling

We do not persist prompt or completion content by default — only request metadata needed for metering, routing, analytics and abuse prevention. See the privacy policy for the full retention picture, and the providers page for each upstream provider's retention policy.

Reporting a vulnerability

If you believe you have found a security issue, please email security@prorouter.com with steps to reproduce. Please do not test against other users' accounts, run denial-of-service tests, or access data that is not yours. We will acknowledge your report and keep you updated on remediation.