Skip to main content

Creating a Company & Getting Your Keys

Every integration starts with a Company account. A company owns:

  • One or more dashboard users (starting with an OWNER)
  • One or more API keys, each paired with an access key ID

Enterprise customers who need a custom plan or a managed setup can contact support@brimsage.com instead of self-registering you'll receive the same credentials described below.

Register your company​

POST /v1/account/register
Content-Type: application/json
{
  "company_name": "Test Company",
  "full_name": "New Owner",
  "email": "new@company.co.ls",
  "password": "a-strong-password",
  "webhook_url": "https://company.co.ls/webhooks/attestid"
}

This single call:

  1. Creates your company account (status = active, plan = starter 500 verifications/month).
  2. Creates an OWNER dashboard user for email / password.
  3. Issues your first API key, in the test environment.

Response​

{
  "id": "5b1e...",
  "company_name": "Test Company",
  "email": "new@company.co.ls",
  "status": "active",
  "plan": "starter",
  "created_at": "2026-07-07T10:00:00",
  "access_key_id": "ak_test_9f2c...",
  "api_key": "sk_test_7d0a...b31f",
  "access_token": "eyJhbGciOi...",
  "token_type": "bearer",
  "role": "owner",
  "company_id": "5b1e..."
}
FieldWhat it is
access_key_idPublic identifier for the key pair. Prefixed ak_test_ or ak_live_. Safe to store in config, logs, or dashboards.
api_keyThe secret. Prefixed sk_test_ or sk_live_. Shown exactly once if you lose it you must issue a new key (there is no "forgot my key" recovery).
access_tokenA dashboard session token for the new OWNER user (8-hour expiry) used for dashboard endpoints, not the KYC API.

If the email is already registered, the endpoint returns 409 Conflict.

Issuing additional keys​

Your company can hold multiple key pairs e.g. separate test and live keys, or a key per environment/team. Once authenticated (dashboard session or an existing API key), issue more:

POST /v1/account/me/keys
{ "environment": "live" }

Response (api_key shown once, same as registration):

{
  "key_id": "8a...",
  "access_key_id": "ak_live_2b7e...",
  "key_prefix": "ak_live_2b7e",
  "environment": "live",
  "api_key": "sk_live_c94f...a01d"
}

List keys (prefixes only full secrets are never retrievable after creation):

GET /v1/account/me/keys

Revoke a key (irreversible):

DELETE /v1/account/me/keys/{key_id}

Key formats​

  • access_key_id starts with ak_live_ or ak_test_. This is a public identifier, safe to store in config or logs.
  • api_key starts with sk_live_ or sk_test_. This is a secret. It is shown to you exactly once, at creation time AttestID never stores or displays the raw value again, so treat it like a password and store it in a secrets manager.

Use test keys against non-production data while integrating, and switch to live keys when you go live.

Next step​

Once you have access_key_id + api_key, continue to Authentication & SDK Token Generation to see how they're used to authenticate requests and generate the short-lived token your frontend/mobile SDK actually uses.