Authentication
Authentication
Intellia API supports two authentication methods: API Keys for server-to-server communication and JWT tokens for user-authenticated requests.
API Key Authentication
API keys are the recommended way to authenticate programmatic access to the Intellia API. They can be created in the Organization > API Keys section.
Creating an API Key
- Navigate to Organization > API Keys in the UI
- Click Create API Key
- Provide a Description (required) - e.g., “Production Integration”
- The system will generate an API key
Permissions Model
When creating an API key, you can grant permissions to specific resources. The permission structure follows this pattern:
{
"resource_name": {
"read": boolean,
"write": boolean
}
}Available permission scopes include:
agents- Read/Write agent configurationsconversations- Read/Write conversationsknowledge_bases- Read/Write knowledge basestools- Read/Write tool attachmentsintegrations- Read/Write integrationsprompts- Read/Write promptsassume_role- Generate assume-role tokenswebhooks- Manage webhooks
Using API Keys in Requests
Include the API key in the Authorization header:
curl -H "Authorization: Bearer YOUR_API_KEY" \
https://api.intellia.com.au/orgs/{organizationId}/agentsAPI Key Features
| Feature | Details |
|---|---|
| Creation | Only organization Admins and Owners can create API keys |
| Listing | Only organization Admins and Owners can view all API keys |
| Permissions | Limited by the specific permissions granted during creation |
| Restrictions | Some sensitive endpoints (like key management) cannot be accessed with API keys |
| Source Tracking | The API logs identify requests made with API keys (source: api-key) |
API Key Limitations
The following operations cannot be performed with API keys (these require user authentication):
- Creating, listing, or managing API keys themselves
- Billing and subscription operations
- Assume-role token generation (unless specifically permitted)
Assume Role Tokens
For scenarios where you need to generate temporary authentication tokens for end-users (e.g., embedding chat widgets), use the assume-role endpoint.
POST /orgs/{organizationId}/assume-roleRequired: API key with assume_role write permission
Request Body:
{
"userId": "user-123",
"userEmail": "user@example.com",
"userName": "John Doe"
}Response:
{
"token": "eyJhbGci...",
"expiresAt": "2024-01-01T12:00:00Z",
"userId": "user-123",
"organizationId": "org-456",
"role": "chat"
}Features:
- Users are automatically created if they don’t exist
- New users are assigned to the Default user group
- Tokens expire after 2 hours
- Ideal for frontend chat widgets and embedded applications
Best Practices
- Never expose API keys in frontend code - Always proxy through your backend
- Use specific permissions - Grant only the minimum permissions needed
- Rotate keys regularly - Create new keys and delete old ones periodically
- Use assume-role for end users - Generate short-lived tokens instead of sharing API keys