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
  • One or more client certificates, which your backend presents on every API-key request

Getting set up takes four steps: register, verify your email, issue a client certificate, then use your keys.

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

1. 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",
  "plan": "free",
  "webhook_url": "https://company.co.ls/webhooks/attestid"
}

plan and webhook_url are optional. Self-service registrations start on the Free plan (50 verifications in total, which never reset) unless you choose another plan.

This call creates your company and an OWNER dashboard user. It doesn't issue an API key or allow login yet. First, AttestID emails a verification link to prove you control the address.

Response (201 Created)​

{
  "id": "5b1e...",
  "company_name": "Test Company",
  "email": "new@company.co.ls",
  "status": "active",
  "plan": "free",
  "created_at": "2026-10-09T10:00:00",
  "company_id": "5b1e...",
  "message": "Check your email to verify your address — no API key or dashboard login is issued until it's confirmed."
}

If the email is already registered, the endpoint returns 409 Conflict. Passwords must meet the strength policy, or the request is rejected with 422.

2. Verify your email​

Click the link in the verification email (it expires after 24 hours). Verifying activates the account and automatically issues your first API key, in the test environment. The dashboard shows it once.

If you're calling the API directly, the link's token goes to:

POST /v1/account/verify-email
Content-Type: application/json
{ "token": "the-token-from-the-email" }

Response:

{
  "message": "Email verified — you can now log in.",
  "company_id": "5b1e...",
  "key_id": "8a...",
  "access_key_id": "ak_test_9f2c...",
  "key_prefix": "ak_test_9f2c",
  "environment": "test",
  "api_key": "sk_test_7d0a...b31f"
}

Lost the email? Request a new link with POST /v1/account/resend-verification and { "email": "..." }. It always returns the same message, whether or not the address is registered, so it can't be used to discover accounts.

3. Issue a client certificate​

AttestID requires mutual TLS on every API-key request, so your backend needs a client certificate before it can call the API. Generate a private key and CSR on your server, then paste the CSR into Client Certificates in the dashboard. Your private key never leaves your server.

See Client Certificates (mTLS) for the commands and renewal steps.

4. Issue more keys​

Your company can hold multiple key pairs, for example separate test and live keys, or a key per environment or team. Issue them from the dashboard (API Keys) or with an existing API key:

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

Response (the api_key is shown once, as at verification):

{
  "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 can't be retrieved after creation):

GET /v1/account/me/keys

Revoke a key (irreversible):

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

Rotating a key without downtime​

Rotate keys from the dashboard (API Keys → Rotate). Rotation is two-step:

  1. AttestID issues a replacement key in the same environment and shows it once. The old key keeps working for 24 hours, so you can roll the new key out to your servers.
  2. When every server uses the new key, confirm the rotation to cut the old key off straight away. If you don't, it stops working on its own when the 24 hours are up.

The key list shows each key's age, so you can see which keys are due for rotation.

Key formats​

  • access_key_id starts with ak_live_ or ak_test_. It's a public identifier, safe to store in config or logs.
  • api_key starts with sk_live_ or sk_test_. It's a secret, shown to you exactly once. AttestID stores only a hash and can't show it again, so treat it like a password and keep 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 your keys and a client certificate, continue to Authentication & SDK Token Generation to see how they're used to generate the short-lived token your frontend or mobile SDK uses.