Authentication

The public API accepts a workspace API key in the standard Bearer header:

Authorization: Bearer YOUR_API_KEY

curl \
  -H "Authorization: Bearer YOUR_API_KEY" \
  https://api.reminix.com/v1/workspace

The response names the workspace the key belongs to:

{ "id": "…", "name": "Example Workspace" }

API keys belong to a workspace

A key acts as a workspace, not a person. It keeps working if the person who created it leaves the workspace. It never carries a user session, so nobody can use it to sign in.

Creating a key

Workspace owners create keys in the app, under Settings → API Keys:

1. Give it a name that says where it’s used, such as production-backend.
2. Choose what it may do (see Scopes). It’s read-only unless you choose otherwise.
3. Copy the secret. We show it once and you can’t view it again, so put it in your secret manager straight away.

The list of keys shows only what is safe to show: the name, the first few characters, the access, and when it was created and last used. If a secret is lost, create a new key and revoke the old one.

Revoking and rotating

Owners can revoke a key at any time under Settings → API Keys. It stops working on the next request, and you can’t restore it.

To rotate a key without downtime:

1. Create a new key.
2. Switch your integration to it.
3. Revoke the old key.

Scopes

You give every key and token scopes when you create it, and it can do only what they allow. A scope names a group of endpoints and whether it may read or change them: workspace:read reads the workspace profile, workspace.members:read reads members and pending invitations, and workspace.audit:read reads the audit trail. The API reference shows the scope each endpoint needs.

When you create a credential, you choose:

Access	What it gets
Read only	The default. Every read scope that exists at creation. Scopes added later are not included.
Full access	Everything, including scopes added to the API later.
Custom	Exactly the scopes you tick.

Give an integration only what it needs. Calling an endpoint the credential wasn’t given returns 403 forbidden:

{
  "error": {
    "code": "forbidden",
    "message": "This credential is not granted the workspace.audit:read scope",
    "requestId": "…"
  }
}

You can change an API key’s access at any time: on Settings → API Keys, click Edit access on its row. The key stays the same, so nothing needs updating where it’s used, and the change applies within a minute. You can’t change a personal access token’s scopes: create a new token and revoke the old one.

Personal access tokens

A personal access token (pat_…) acts as you, not as a workspace. Use one for your own scripts, CI jobs and the command line. Create it in the app under Account → API tokens, or let the command line create one. Its login opens your browser, and once you approve, the command line creates the token for that computer and stores it for you.

A personal access token:

• works in the workspaces you choose when you create it, all of yours or specific ones, with the scopes you give it;
• is also limited by your role in each workspace. For example, GET /v1/workspace/audit-events is for owners only, as the audit page is in the app. (A workspace API key is the workspace itself and has no role.)
• expires when you choose: after 30 days, 90 days, a year, or never;
• identifies you at /v1/user/me:

curl \
  -H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN" \
  https://api.reminix.com/v1/user/me

{
  "id": "…",
  "name": "Casey Customer",
  "email": "casey@example.com",
  "workspaces": [
    { "id": "…", "name": "Example", "slug": "example", "role": "owner" }
  ]
}

Everywhere else, a personal access token has to say which workspace it’s acting in, with the X-Workspace header set to the workspace’s slug. The call then runs with your membership in that workspace and the token’s scopes:

curl \
  -H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN" \
  -H "X-Workspace: example" \
  https://api.reminix.com/v1/workspace

Without X-Workspace the request fails with 400. A workspace you’re not a member of, one the token wasn’t created for, or a scope the token doesn’t have, fails with 403. Workspace API keys ignore the header, because a key already is its workspace, and they’re never accepted on /v1/user/*.

Like API keys, we show tokens once, and you can revoke them from the same page. They stop working at once if they expire or your account is suspended.

Apps and AI agents (OAuth)

Apps, including AI agents connecting their tools, can act for a person without ever holding a key, because the product is an OAuth 2.1 authorization server. The app sends the person to sign in. They choose a workspace and approve what the app may do, and the app gets a short-lived access token for the API.

• Discovery: https://api.reminix.com/.well-known/oauth-authorization-server/auth lists every endpoint. Apps can register themselves (dynamic client registration); registering grants nothing until a person approves.
• Scopes: an app asks for the same scopes, such as workspace.audit:read, plus offline_access for a refresh token. The person can give it fewer.
• One person, one workspace: a token acts for one person in one workspace, with that person’s role, so it needs no X-Workspace header. Request it for the resource https://api.reminix.com/v1.
• Disconnecting: the person can disconnect the app at any time under Account → Connected apps. Its tokens stop working on the next request.

When authentication fails

A missing, malformed, invalid or revoked credential gets a 401 with the standard error envelope:

{
  "error": {
    "code": "unauthorized",
    "message": "Unauthorized",
    "requestId": "…"
  }
}

The response is the same whatever the cause, so it gives nothing away to someone guessing keys. Browser session cookies are never accepted on the public API.