Authentication and API keys

The Auditmark API authenticates with an organization API key. Send the key as a bearer token in the Authorization header on every request to /v1.

Authorization: Bearer <your-api-key>

A key starts with the prefix ak_. The admin app shows the full key once when you create it.

Example request

GET /v1/templates HTTP/1.1
Host: api.auditmark.io
Authorization: Bearer ak_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Creating a key

You create and manage keys in the admin app at app.auditmark.io under Settings, on the API keys tab. You cannot create a key by calling the API. Creating a key needs an admin who is signed in.

Select Create key to open the Create API key dialog. It has three fields.

Field	What it does
Name	A label so you can tell keys apart, for example "Scheduling integration".
Access	Choose Read & write or Read only. This records the key's intended scope.
Expires	Choose Never, 30 days, 90 days, or 365 days.

When you select Create, Auditmark shows the full key once. Select Copy to put it on your clipboard. After you close the dialog, only the key's prefix and a hash are stored, so the key cannot be shown again. Copy it to a secure location before you close the dialog. If you lose a key, revoke it and create a new one.

Managing keys

The API keys tab lists every key for your organization in a table with these columns.

Column	What it shows
Name	The label you gave the key.
Prefix	The first part of the key, so you can identify it without seeing the full value.
Access	Read & write or Read only.
Created	When the key was created.
Last used	The last time the key authenticated a request, or a dash if it has not been used.
Expires	The expiry date, or a dash if the key never expires.
Status	Active, Expired, or Revoked.

A key with no requests yet shows a dash under Last used. When you have no keys, the table reads "No API keys yet."

Revoking a key

To stop a key from working, select Revoke on its row and confirm in the dialog. Revocation takes effect immediately and cannot be undone. Apps still using the key stop authenticating right away. The key's status changes to Revoked and the Revoke action no longer appears on that row.

A key whose expiry date has passed shows the status Expired and stops authenticating on its own, without you revoking it.

Scope and isolation

A key is scoped to one organization. It can only read and write data that belongs to that organization. There is no cross-organization access, and no way to point a key at another organization's data.

Within that organization, a key acts with the API role. The API role can use the machine endpoints under /v1, but it can never drive admin-only interactive features or AI features. Those run only for a signed-in human in the admin app, so an API key cannot trigger an unmetered model call or a human-only admin action.

When you create a key you choose its access, Read & write or Read only. Set Read only for an integration that never needs to write, so each key's intended scope is recorded and visible in the keys list.

You can hold several keys per organization. This lets you give each integration its own key so you can revoke one without affecting the others.

Key security checklist

Store keys in environment variables or a secrets manager, not in source code.
Rotate keys periodically, or on any suspected exposure.
Create one key per integration so revocation is surgical.
Give a key Read only access when the integration never needs to write.
Set an expiry on keys that are used for short-lived integrations.