API keys
Every REST call and every MCP call made with a key sends it in the Authorization header:
Authorization: Bearer nxa_3f9c…Keys are created in the app under Settings → API → Organization API keys.
Key types
Section titled “Key types”A key always belongs to one workspace (organization) and only ever acts on that workspace. It does not follow anyone’s account switcher.
| Organization key | Personal key | |
|---|---|---|
| Belongs to | The workspace | One team member, in one workspace |
| Acts as | The workspace owner | That team member, with their permissions |
| Who can create it | Owners, admins and managers | Any active team member |
| Stops working when | It is revoked or rotated | It is revoked or rotated, or the member leaves the workspace |
| Use it for | Integrations that run on their own: a website, a report, a backend job | A person’s own tools, scripts or AI client |
Use an organization key for anything unattended. A personal key dies with the person’s seat, which is right for a person’s tools and wrong for your website.
Old personal keys
Section titled “Old personal keys”A key made before 24 September 2026 shows on the same page as Old personal API key
(nxa_ + 32 characters). It acts on whichever workspace its owner has open at that moment, so
switching accounts changes what connected tools see. It keeps working with full access, but
replace it with an organization key.
Access levels
Section titled “Access levels”When you create a key you also choose what it may do:
- Full access: every endpoint and every MCP tool, as the user the key acts as.
- Contacts: create & update only: only
POST /v1/contacts. Every other endpoint and the MCP server refuse it.
You can also make a test key for the contacts endpoint. It validates every request and writes nothing. See Access levels and test keys.
Shown once
Section titled “Shown once”The full key is shown only once, right after you create or rotate it. NexaCloser stores only a hash, so nobody can show it again, not even support. After that the app shows the key’s name, type, last four characters and when it was last used (updated at most once a minute).
Lost a key? Rotate it.
Rotate a key
Section titled “Rotate a key”Rotate replaces the key with a new one that keeps the same name, type and access level. The old key stops working immediately, so update the systems that use it right after.
- Organization keys: owners, admins and managers can rotate them.
- Personal keys: only their owner can rotate them, because the new key acts as that person.
Revoke a key
Section titled “Revoke a key”Revoke turns the key off for good. Anything using it fails from the next request on. This cannot be undone.
- Organization keys: owners, admins and managers.
- Personal keys: their owner, or an owner, admin or manager of the workspace.
Keys do not expire by themselves. Rotate them on your own schedule, and whenever someone who had a copy leaves.
Keep keys safe
Section titled “Keep keys safe”- Store keys in environment variables or a secret manager, never in code or a repository.
- One key per integration, named after it, so you can rotate or revoke one without touching the rest.
- Give each integration the smallest access level that works: a website form needs Contacts: create & update only, not full access.
- Never put a key in a URL. URLs end up in logs and browser history.
Other credentials
Section titled “Other credentials”| Credential | Looks like | Used for |
|---|---|---|
| API key | nxa_… (test keys nxa_test_…) |
REST API and MCP |
| MCP server token | mcps_… |
MCP clients without OAuth. See MCP auth |
| MCP OAuth token | mcp_at_… |
Issued to MCP clients by the OAuth flow, 1 hour, refreshed by the client |
| Webhook token | any secret | The X-Webhook-Token header of an inbound webhook |