Skip to main content
By the end of this page you will have:
  1. An ak_live_* API key.
  2. Confirmed authentication with /auth/whoami.
  3. Listed your team’s evaluations.
  4. Dry-run a new evaluation (no spend, no DB write).
  5. Created a real evaluation.

1. Mint an API key

Go to Settings → API keys in the dashboard and click Create key.
Create API key dialog
Pick the scopes you need. For this quickstart, select evaluations:read, evaluations:write, and autousers:read. See Authentication for the full vocabulary. The plaintext key is shown once. Store it as AUTOUSERS_API_KEY in your secret manager. We store only its sha256 hash; if you lose it, mint a new one.
Keys begin with ak_live_. Treat them like passwords — never check them into source, never paste them into chat. They inherit the team membership of whoever minted them.

2. Confirm authentication

Response:
If you see {"error":{"type":"authentication_error",...}}, your key is wrong or revoked. Mint a fresh one.

3. List evaluations

The response is a Stripe-style paginated list:
Pass starting_after=<last_id> to fetch the next page. See Pagination.

4. Dry-run a new evaluation

Every billable POST that runs autousers supports dryRun: true. The server validates the payload, returns a cost estimate, and writes nothing to the database. Use this in CI to fail fast on a malformed config before spending tokens.
Response:
The dry-run echoes the validated payload as wouldCreate so the caller can confirm exactly what the live POST would persist.

5. Create the real evaluation

Drop dryRun: true and re-issue the same request:
Response (status 201):
To actually run the autousers, POST to /v1/evaluations/{id}/run-autousers. See the Evaluations concept guide.

Next steps

Stop polling — use webhooks

Get notified when an autouser run completes.

Wire the CLI into CI

autousers eval create --template=accessibility in GitHub Actions.