Skip to main content
Applies to:
  • Plan -
  • Deployment -

​
Summary

Issue: Calls to the impersonation endpoint to create API keys return 403 with the message API keys cannot create API keys. Cause: Braintrust intentionally removed the ability for API keys to create other API keys as a security measure. Resolution: Use service tokens scoped to the appropriate projects and permission groups, or ask users to create their own API keys upon onboarding.

​
Resolution steps

​
If you need programmatically scoped access to specific projects

​
Step 1: Create a permission group (Enterprise only)

In Settings → Groups, create a group scoped to the projects your users need access to.
Note: Project-scoped permission groups require an Enterprise plan. On Starter or Pro plans, skip to Step 2 and use the service token’s built-in permissions instead.

​
Step 2: Create a service token

In Settings → Service Tokens, create a service token. On Enterprise plans, tie it to the permission group from Step 1. On other plans, configure the token’s permissions directly. Use this token in place of the per-user API keys you were generating via impersonation.

​
Step 3: Update your integration

Replace calls to the impersonation endpoint with the service token in your requests.
Note: Programmatic creation of service tokens via API key may also be restricted. If you receive a similar 403 error when creating service tokens programmatically, create them manually in the Braintrust UI.

​
If you need access scoped to individual user permissions

​
Step 1: Invite users to the organization

Invite users to your Braintrust org. Their API keys will automatically inherit their assigned permissions.

​
Step 2: Ask users to create their own API keys

Direct users to Settings → API Keys to create a personal key. Include this step in your onboarding instructions.

​
Notes

  • Per-user API keys can no longer be created centrally on behalf of users.
  • Service tokens with appropriate project permissions are the recommended replacement for scoped programmatic access.
  • If you previously maintained one service account per user, consider consolidating — per-user service accounts require a permissions-sync layer and create double lifecycle management overhead.