Authentication and access keys

Create a service account and an access key, send it as a Bearer token, understand what it can reach, and revoke or rotate it.

Scripts and integrations sign in with an access key. A key belongs to a service account, which holds roles exactly like a person does.

Create a key

Before you start: You need permission to manage members in the workspace (the iam:manage_members permission, which the workspace owner always has).

1. Open Team & Permissions › Access keys.
2. Click New service account, enter a Name that says what it is for (for example "CI deploy" or "Zapier"), and click Create.
3. In the Give it a role… box, choose one or more roles. A service account with no role can authenticate but cannot read or change anything.
4. Click Keys, type a New key name (for example production), and click Create key.
5. Click Copy. The key is shown once, as axk_ followed by random characters. You cannot see it again; if you lose it, create another and revoke the old one.

Send the key

Put the key in an Authorization header as a Bearer token on every request.

curl -s https://axisiq.co/api/v1/orgs/{orgId}/iam/me \
  -H "Authorization: Bearer axk_…"

Find {orgId} under Settings › Organization ID.

The call above returns what the key is allowed to do:

{
  "data": {
    "is_owner": false,
    "policy": [
      { "effect": "allow", "actions": ["records:read", "records:create"], "resources": ["*"] }
    ]
  }
}

policy is the combined rule list from all of the service account's roles, in the format described in Policy format.

What a key can reach

Permissions

A key has exactly the permissions of its roles. A service account is never the workspace owner, so it never has implicit full access. To let a key do something, edit its role in Team & Permissions › Roles. To give it a one-off exception such as "everything except deleting", use Advanced rules on the role.

Some permissions are checked against a specific item rather than the whole workspace: a record type, a queue, a drive space, a form, a site. Those are listed in the Permissions reference.

Revoke and rotate

• Revoke a single key: Team & Permissions › Access keys, click Keys on the service account, then Revoke. The key stops working immediately.
• Delete a service account to stop all its keys at once.
• If the person who created a key is removed from the workspace, the keys they created stop working.
• Keys show last used and never used so you can find ones to retire.

To rotate: create a second key, deploy it, then revoke the first.

Important: Treat a key like a password. Keep it in a secrets manager or CI secret, never in client-side code or a public repository. Anyone holding it can do whatever its roles allow.

Audit

Changes a key makes to records appear in the record history with the actor shown as a service account, so you can tell script activity apart from people. See Records.

Errors you may see

See Errors for the full list.