import { Code } from '@astrojs/starlight/components';
import { apiHost, apiOrigin, consoleOrigin } from '../../../lib/docs-env';

This guide walks through creating an account, generating an API key, and making
your first request. The whole flow takes about two minutes.

## 1. Sign up

Create an account from the console:

- US region: <a href={consoleOrigin('us')}>{consoleOrigin('us')}</a>
- EU region: <a href={consoleOrigin('eu')}>{consoleOrigin('eu')}</a>

Pick the region your data should live in. We do not move customer data between
regions, and API keys are bound to the region they were issued in — a
`ah_sk_us_…` key only works against <code>{apiHost('us')}</code>.

## 2. Generate an API key

In the console, open **Developers → API keys → New API key** and choose:

- **Mode** — `test` for development, `live` for production traffic.
- **Scopes** — at minimum `applicants:write` and `sessions:write` for the
  examples below.

The key is shown once. Copy it immediately and store it in a secrets manager
(for example, 1Password, or your own secrets manager). The key looks like:

```
ah_sk_us_test_<43 random chars>
```

The prefix encodes region (`us` / `eu`) and mode (`test` / `live`); the SDK
uses it to pick the right endpoint automatically.

## 3. Make your first request

Identify the key with `GET /v1/me`:

<Code
  code={`curl -i ${apiOrigin('us')}/v1/me \\\n  -H "Authorization: Bearer ah_sk_us_test_<your-key>"`}
  lang="bash"
/>

Successful response:

```json
{
  "data": {
    "id": "key_01ABC",
    "object": "api_key",
    "org_id": "org_01XYZ",
    "mode": "test",
    "region": "us",
    "scopes": ["applicants:write", "sessions:write"]
  }
}
```

Every response includes an `X-Request-Id` header. Surface it in your logs —
support tickets that include the request ID get triaged faster.

## Next steps

- Browse the [interactive reference](/reference) to see every endpoint.
- Read the [error code reference](/api/errors/) so your client handles the
  full envelope, including `request_id` and `doc_url`.
- Integrate directly against the REST API: treat the wire shapes documented in
  the reference as the contract. They are generated from the same Zod schemas
  the server uses to validate input, so they will not drift.