API authentication
Server API requests carry a credential in the Authorization header. Keep the credential on your server, load it from a secret store or an environment variable, and never put it in client-side code, a URL or a log line.
Authorization: Bearer YOUR_API_KEYKeys and base URLs
Create and manage server API keys in the Backoffice under Integrations & API. The secret is shown once when a key is created or rotated, so store it immediately. Send each request to the base URL of the API you call:
| Environment | Base URL | Key prefix | APIs |
|---|---|---|---|
| Production | https://collect.noxtica.com | sk_prod_ | Identity verification API, Webhook endpoints API, Risk scoring and agent trust API, Protected actions API, Device intelligence API, Mobile and device identity API, Telemetry ingestion API, Observability query API, Health and public key endpoints |
| Production ingest host | https://ingest.noxtica.com | Telemetry ingestion API, Observability query API | |
| Production | https://backoffice.noxtica.com | MCP server | |
| Production (not yet deployed) | https://pulse.noxtica.com | Pulse tenant API |
Credentials
ApiKeyAuth
Format: Authorization: Bearer sk_<random>.
Server-to-server tenant API key. Header: Authorization: Bearer sk_.... Scopes are self-mintable per tenant; the scope required by each operation is listed in that operation’s security block. Recognized KYC/KYB/KYM scopes: write:identity (verify, batch, reverify, evidence, sessions, erasure and activate — all share this one scope), read:identity_details (the identity details read routes only; it authorises no write and write:identity does not imply it), write:kyc_review_decision (the review decision route only; it reads nothing and write:identity does not imply it), write:kym (KYM transactions). A key keeps its scopes until a tenant administrator changes them (Edit scopes on the key in the Backoffice, API Configuration); create a new key as the other way to add one.
The read:evidence scope opens the evidence image routes only (the list, the access grant and the access log; the signed URL a grant returns needs no key). It authorises no write, and neither write:identity nor read:identity_details implies it.
Used by: Identity verification API, Webhook endpoints API, Risk scoring and agent trust API, Protected actions API, Device intelligence API, Mobile and device identity API, Observability query API.
SessionTokenAuth
Format: Authorization: Bearer kycs.<tenant>.<secret>.
Opaque hosted-session bearer token, minted once by the matching POST .../sessions S2S call and never re-issued. The tenant id rides inside the token itself. Additionally origin-enforced against the tenant’s ALLOWED_ORIGINS allowlist — a missing or disallowed Origin header refuses with 403 origin_not_allowed even given a valid token.
Used by: Identity verification API.
ApmIngestKeyAuth
Format: Authorization: Bearer sk_apm_<random>.
Dedicated ingestion key (sk_apm_..., matching ^sk_apm_[A-Za-z0-9_-]{24,256}$), created per project and environment under Integrations & API → Ingestion API keys. It carries an allowlist of signals chosen at creation and is the ONLY credential the ingestion operations accept: a server API key (sk_...), however broad its scopes, is rejected there, and an sk_apm_ key is rejected on every other route.
Used by: Telemetry ingestion API.
CodingAgentKeyAuth
Format: Authorization: Bearer cak_<random>.
Coding-agent read key (Authorization: Bearer cak_..., matching ^cak_[A-Za-z0-9_-]{24,256}$), created under Integrations & API → Coding agent keys with a chosen set of scopes. It is accepted only by the coding-agent read operations, on the ingestion hosts; a server API key (sk_...) or an ingestion key (sk_apm_...) is rejected there.
Used by: Observability query API.
McpTokenAuth
Format: Authorization: Bearer mcp_<random>.
MCP token (Authorization: Bearer mcp_...) created under Integrations & API, MCP tokens. A static opaque bearer token, not OAuth. It is accepted only by this endpoint.
Used by: MCP server.
tenantKey
Format: Authorization: Bearer sk_prod_<32 hex>.
The platform’s tenant API key (minted in the Backoffice; scopes read:pulse, write:pulse), for the tenant’s own back-end on /pulse/v1/tenant/* only. Looked up through an HMAC hash; a device token or a web session is refused.
Used by: Pulse tenant API.
Scopes
Choose the narrowest scopes that cover what a key has to do. A key without the scope an operation requires is rejected.
Failed authentication
A missing, malformed or revoked credential, and a credential without the required scope, are rejected before the operation runs. See Errors for the status codes and bodies.
A server API key is checked before the operation runs. These are the answers the check itself gives:
| Status | Error code | Meaning |
|---|---|---|
401 | invalid_api_key | The key is missing, malformed, unknown, revoked, or belongs to a suspended or deleted organisation. The answer is identical for every cause, so it does not reveal which one applies. |
403 | The key is valid but does not carry the scope the operation requires. The body names the missing scope. | |
503 | api_key_auth_unavailable | Noxtica could not read the key’s record. This is a temporary fault on Noxtica’s side and says nothing about your key. Retry after the Retry-After delay; do not treat it as a revoked key. The Retry-After header carries the delay in seconds. |
A 401 means the key was refused. A 503 with api_key_auth_unavailable does not: it says nothing about your key, so wait for the Retry-After delay and send the request again. Every operation that takes a server API key lists this answer in its Responses table.
This page is generated from the Noxtica OpenAPI specification release v0.16.1: kyc.yaml version 1.14.1-2026-11-07 (SHA-256 dc9e4b53d94c), mcp.yaml version 0.1.0-2026-10-27 (SHA-256 1a4875efa736), pulse.yaml version 0.10.0-2026-10-31 (SHA-256 6864df34b799), v1.yaml version 1.5.1-2026-11-03 (SHA-256 41508500e857). Do not edit it by hand.