Authentication
Authenticate trusted backend requests with API keys or tenant-signed JWTs.
Deeplinq supports two server-to-server authentication models. Both resolve the same internal organization and user identity before authorization.
Engine-issued API keys
API keys are the fastest path to a first request. Send the key as a bearer token:
Authorization: Bearer sk_dl_...Three key classes are available:
| Key class | Identity behavior | Typical use |
|---|---|---|
| Organization | Operates at organization scope; may add per-user attribution | Trusted service or integration |
| Role ceiling | Limits the maximum roles a caller may exercise | Delegated backend service |
| User-bound | Pins the subject to one user | Personal access and developer tooling |
An organization or role-ceiling key may include an end-user attribution header:
X-End-User-Id: user_123The header affects user-level metering and limits. It does not turn an organization key into a browser-safe credential.
Tenant-signed JWTs
For production B2B2C applications, the established pattern is to mint a short-lived JWT in your trusted backend for each user session or request. The engine validates it locally against the public key registered for your organization.
JWT validation requires:
- a supported asymmetric algorithm: RS256, ES256, or EdDSA;
- the configured Deeplinq audience;
- a bounded expiration time;
- a stable user subject;
- the identity-provider organization reference registered during onboarding.
Authorization: Bearer eyJhbGciOiJFZERTQSIs...Security rules
- Keep API keys and private signing keys in a server-side secret manager.
- Use HTTPS for every non-local request.
- Mint narrowly scoped, short-lived JWTs.
- Rotate credentials using overlapping validity windows.
- Never place a Deeplinq credential in client-side JavaScript, mobile bundles, URLs, or logs.