Authentication
How Soniox API keys work, which key to use on servers and in client apps, and how to send a key with REST and WebSocket requests.
Every request to the Soniox API is authenticated with an API key. The key identifies your project, and usage and cost count toward that project.
API keys
Create API keys in the Soniox Console. Each key belongs to one project, and you can limit what it may do with API key permissions.
Server keys and client keys
- On your servers, use a regular API key from the Console. Keep it in your secrets manager and never ship it in a browser, mobile app, or public repository. Anyone who has it can spend your credits until you revoke it.
- In client apps, use a temporary API key. Your backend mints it from a regular key and hands it to the client. It is short-lived and carries restrictions, such as which service it is valid for and whether it may open only one stream.
To manage projects and API keys across your organization from your own tooling, use an organization API key with the Organization API.
REST requests
Send the key in the Authorization header:
For example:
WebSocket connections
Send the key when you open the connection, in the Authorization header or in the WebSocket protocols list. See WebSocket authentication for both options, connection timeouts, and the connection limit.
Still sending api_key in the start message? Follow Migrate WebSocket authentication.
Regional endpoints
If your project uses data residency, send requests to the API domain for its region, for example api.eu.soniox.com instead of api.soniox.com. See regional endpoints for the full list.