Agent authentication
Overview
When building conversational agents, you may need to restrict access to certain agents or conversations. ElevenLabs provides multiple authentication mechanisms to ensure only authorized users can interact with your agents.
Authentication methods
ElevenLabs offers two primary methods to secure your conversational agents:
Generate temporary authenticated URLs for secure client-side connections without exposing API keys.
Restrict access to specific domains or hostnames that can connect to your agent.
Using signed URLs
Signed URLs are the recommended approach for client-side applications. This method allows you to authenticate users without exposing your API key.
The guides below uses the JS client and Python SDK.
How signed URLs work
- Your server requests a signed URL from ElevenLabs using your API key.
- ElevenLabs generates a temporary token and returns a signed WebSocket URL.
- Your client application uses this signed URL to establish a WebSocket connection.
- The signed URL expires after 15 minutes.
Generate a signed URL via the API
To obtain a signed URL, make a request to the get_signed_url endpoint with your agent ID:
The curl response has the following format:
Connecting to your agent using a signed URL
Retrieve the server generated signed URL from the client and use the signed URL to connect to the websocket.
Signed URL expiration
Signed URLs are valid for 15 minutes. The conversation session can last longer, but the conversation must be initiated within the 15 minute window.
Using allowlists
Allowlists provide a way to restrict access to your conversational agents based on the origin domain. This ensures that only requests from approved domains can connect to your agent.
How allowlists work
- You configure a list of approved hostnames for your agent.
- When a client attempts to connect, ElevenLabs checks if the request’s origin matches an allowed hostname.
- If the origin is on the allowlist, the connection is permitted; otherwise, it’s rejected.
Configuring allowlists
Allowlists are configured as part of your agent’s authentication settings. You can specify up to 10 unique hostnames that are allowed to connect to your agent.
Example: setting up an allowlist
Choosing an authentication method
Configure one authentication method per agent:
- Use signed URLs (
enable_auth) for authenticated client sessions. - Use allowlists (
allowlist) for hostname-based access control.
Do not configure signed URLs and allowlists together on the same agent. Choose the method that matches your deployment model.
Example: signed URLs only
Use enable_auth without an allowlist:
Example: allowlist only
Use allowlist without enabling signed URLs:
FAQ
Can I use the same signed URL for multiple users?
This is possible but we recommend generating a new signed URL for each user session.
What happens if the signed URL expires during a conversation?
If the signed URL expires (after 15 minutes), any WebSocket connection created with that signed url will not be closed, but trying to create a new connection with that signed URL will fail.
Can I restrict access to specific users?
The signed URL mechanism only verifies that the request came from an authorized source. To restrict access to specific users, implement user authentication in your application before requesting the signed URL.
Is there a limit to how many signed URLs I can generate?
There is no specific limit on the number of signed URLs you can generate.
How do allowlists handle subdomains?
Allowlists perform exact matching on hostnames. If you want to allow both a domain and its subdomains, you need to add each one separately (e.g., “example.com” and “app.example.com”).
Do I need to use both authentication methods?
No. Configure either signed URLs or an allowlist for each agent. For client-side applications, signed URLs are the recommended default.
What other security measures should I implement?
Beyond signed URLs and allowlists, consider implementing:
- User authentication before requesting signed URLs
- Rate limiting on API requests
- Usage monitoring for suspicious patterns
- Proper error handling for auth failures