Authentication

DeepRoute has two separate identity planes. Operators authenticate to the console with platform JWTs; applications authenticate to the data plane with consumer API keys. The two never mix: a console session cannot call the data plane, and an API key cannot administer the gateway.

Platform identities — the console

Console users sign in with their tenant id, email, and password via POST /auth/login and receive a JWT. The token carries the user's tenant and role; the console sends it as a Bearer token on every /admin/* request. Six platform roles control what each user can see and change.

bash

curl -X POST https://gateway.example.com/auth/login \
  -H "content-type: application/json" \
  -d '{"tenantId": "acme-corp", "email": "ops@acme.dev", "password": "…"}'

Consumer accounts and API keys — the data plane

API consumers register through the developer portal (POST /consumer-auth/signup) and sign in with email and password (POST /consumer-auth/login). The portal session is used to browse the catalogue, request access, and manage keys. The keys themselves are what authenticate data-plane traffic.

bash

curl -X POST https://gateway.example.com/consumer-auth/login \
  -H "content-type: application/json" \
  -d '{"email": "dev@partner.io", "password": "…"}'

Sending the API key

Every data-plane request must carry the key in the x-api-key header. A missing key is rejected with API_KEY_MISSING; an unknown or revoked key with API_KEY_INVALID; a valid key used against a service it has no binding for with BINDING_FORBIDDEN.

bash

curl -H "x-api-key: gw_live_…" \
  https://gateway.example.com/api/v1/orders

Key rotation and grace periods

Keys are versioned. When a key is rotated, the previous version keeps working for a configurable grace period so deployments can roll over without a hard cut. After the grace period, only the newest version authenticates. Every issue, rotation, and revocation is recorded in the audit trail.