Authentication
How people, applications and agents authenticate to Nexra, and how workspace roles control access.
Updated 07/10/2026
On this page
Credentials at a glance
| Credential | Format | Used for |
|---|---|---|
| Session access token | JWT from Nexra sign-in | The console and every /api/console/* and /api/developer-portal/* route |
| Sandbox key | ak_sandbox_<prefix>_<secret> | Requests sent through the sandbox API explorer |
| Live key | ak_live_<prefix>_<secret> | Production API products, once the application's production access is approved |
| MCP access token | OAuth JWT bound to an MCP credential | The /mcp endpoint (see Use the Nexra MCP server) |
| Webhook signing secret | whsec_sandbox_<prefix>_<secret> | Verifying webhook deliveries (see Webhooks) |
| Provider credentials | Stored in a secure vault | Nexra Connect connections; you never send them in API calls |
Every secret is shown once, when it is created or rotated. Nexra stores only a hash, a prefix and the last four characters.
Calling the platform API
Send the access token as a bearer token. If you belong to more than one workspace, choose one with X-Workspace-Id:
curl https://api.nexra.amakoragroup.com/api/developer-portal/me \
-H "Authorization: Bearer $NEXRA_ACCESS_TOKEN" \
-H "X-Workspace-Id: $NEXRA_WORKSPACE_ID"Without X-Workspace-Id, the request uses your oldest active workspace membership. A workspace you are not an active member of returns 403 You do not have access to the requested workspace.
The console API authenticates people. For automation, use the access token of a dedicated workspace member, with the narrowest role the job needs.
API keys
Create keys under Dashboard → Apps → your app → Keys. Choose the scopes (read, write) and an optional expiry date.
GET and HEAD need read; every other method needs write.
Rotate issues a new secret for the same key; the old secret stops working immediately. Revoke disables the key permanently.
Live keys can only be created by a workspace administrator, for an application whose production access has been approved.
Never put keys in URLs, source control or client-side code.
Roles and permissions
Each workspace member has one role. The main ones:
| Role | Typical use |
|---|---|
OWNER, ADMIN | Everything, including members, production access, publishing docs and approving deployments |
DEVELOPER | Build applications, connections, flows and MCP servers; author documentation drafts |
APPROVER | Approve deployments and sensitive actions |
SECURITY_ADMINISTRATOR | Credentials, identity policy, MCP credentials |
DOCUMENTATION_EDITOR | Create and edit documentation drafts |
BILLING_ADMINISTRATOR | Billing and plans |
ANALYST, SUPPORT, COMPLIANCE_REVIEWER, VIEWER | Read-only or scoped operational access |
A request without the required permission returns 403 Workspace permission is required: <permission>.
Approvals always need a different person from the requester: you cannot approve your own deployment, approval request or MCP tool call.
Provider credentials for Connect
Provider secrets are written straight to a secure vault when you create a connection in the console, or with POST /api/console/connect/credential-references. The connection stores only the secret reference. Fields whose names look like secrets (password, apiKey, token, clientSecret, authorization, credential) are rejected if you put them in a connection's settings. See Connections API.