Authenticate API requests

Create and store a key

• Open Developer API, enter Key name, select only the required operations, and create the key.
• Save this key now: the tus_live plain value is returned only once and only its SHA-256 hash is stored.
• Available permissions include messages:send, broadcasts:create, broadcasts:read, complaints:read, complaints:write, complaints:assign, and complaints:attachments:read.
• Complaint assignment requires both complaints:write and complaints:assign. Private evidence download uses its own complaints:attachments:read permission.
• Use separate keys when applications need different authority, and revoke credentials immediately when they are no longer needed.

Header format

Use exactly one of Authorization: Bearer <key> or X-API-Key. Sending both is rejected, and browser session cookies do not authenticate complaint v1 routes. Bearer scheme matching is case-insensitive. Do not place keys in query strings, logs, screenshots, client-side bundles, or public examples.

Authorization: Bearer tus_live_your_key_here

Authorization boundaries

• The key must be valid, unexpired, account-scoped, and include the endpoint scope.
• The account needs an active assigned plan with API access.
• Missing or invalid keys return 401 unauthorized. Missing scope or unavailable API-plan access returns 403 forbidden.
• Keys without explicit permissions are not treated as unrestricted.

Recover authentication errors

• Replace a missing, malformed, expired, or revoked key in the calling service.
• Use a key with the required scope rather than broadening unrelated credentials.
• Review plan API access after forbidden responses.
• Create a replacement before revoking the old key when performing a controlled rotation.