Skip to main content
Telnyx REST API operations declare Bearer authentication in their API reference. Send the API key in the Authorization request header:
Create and manage server-side credentials from API Keys in Mission Control Portal.

​
REST API request

Store the key in a server-side environment variable and reference it from the HTTP client:
Do not place Telnyx API keys in browser JavaScript, mobile applications, public repositories, URLs, logs, or support messages.

​
SDK authentication

Current server-side SDKs read TELNYX_API_KEY from the environment or accept it when constructing a client. Use the generated SDK guides for the current constructor and service method:

​
Credential lifecycle

  1. Create separate keys for development, staging, and production.
  2. Store keys in a secret manager or protected environment configuration.
  3. For a key with an expiration date, deploy a replacement before it expires.
  4. Create a replacement key before rotating an active integration.
  5. Deploy the replacement and confirm a read-only request succeeds.
  6. Revoke the old key from API Keys in Mission Control Portal.
  7. Revoke any key exposed in source control, logs, client code, or chat immediately.
See API error codes and troubleshooting for revoked, forbidden, and invalid credential failures.

​
Product-specific authentication

Do not reuse the REST Bearer pattern where a product defines another protocol:
  • Cloud Storage S3 operations: Use the S3-compatible credentials and AWS Signature Version 4 described by Cloud Storage API endpoints.
  • WebRTC clients: Mint short-lived client tokens on a trusted server; do not expose a Telnyx API key to the client.
  • WebSocket APIs: Follow the authentication message or connection fields documented by that specific WebSocket API.
  • Webhook deliveries: When a product documents Telnyx Ed25519 signing, verify the signature with the account public key. Follow another validation scheme when the selected product defines one. See Webhook fundamentals.