> ## Documentation Index > Fetch the complete documentation index at: https://docs.kirafin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Get access token > Exchange your `client_id` and `password` for a short-lived bearer access token. This is the **only** endpoint that authenticates with just the `x-api-key` header — every other call additionally requires `Authorization: Bearer `. On success the API returns `200` with the standard `{ message, data }` envelope, where `data` carries `access_token`, `token_type` (`Bearer`), and `expires_in` (seconds). The token is valid for **3600 seconds (1 hour)**; there is **no refresh-token flow** — call this endpoint again to obtain a new token when the current one expires or when any request returns `401`. Cache the token and reuse it across requests rather than re-authenticating per call. See the [Authentication](/guides/authentication) guide for the full header reference. {/* version-stamp:start — generated by scripts/stamp-versions.ts, do not edit */} Stable since **2025-01-01** — unchanged in **2026-04-14**. {/* version-stamp:end */} ## OpenAPI ````yaml /openapi/kira-api.2026-04-14.json post /auth openapi: 3.1.0 info: title: Kira API version: '2026-04-14' description: >- REST API for users, KYC/KYB verification, virtual accounts, payouts, recipients, and webhooks. Every request requires an `x-api-key` header and a bearer access token (see Authentication). Pin your account to version `2026-04-14` before integrating. contact: name: Kira API Support email: support@kirafin.ai servers: - url: https://api.balampay.com description: Production - url: https://api.balampay.com/sandbox description: Sandbox security: - bearerAuth: [] apiKeyAuth: [] tags: - name: Authentication - name: Versioning - name: Users - name: Virtual Accounts - name: Quotations - name: Payouts - name: Recipients - name: Reference paths: /auth: post: tags: - Authentication summary: Get access token description: >- Exchange your `client_id` and `password` for a short-lived bearer access token. This is the **only** endpoint that authenticates with just the `x-api-key` header — every other call additionally requires `Authorization: Bearer `. On success the API returns `200` with the standard `{ message, data }` envelope, where `data` carries `access_token`, `token_type` (`Bearer`), and `expires_in` (seconds). The token is valid for **3600 seconds (1 hour)**; there is **no refresh-token flow** — call this endpoint again to obtain a new token when the current one expires or when any request returns `401`. Cache the token and reuse it across requests rather than re-authenticating per call. See the [Authentication](/guides/authentication) guide for the full header reference. operationId: post_auth requestBody: required: true content: application/json: schema: type: object required: - client_id - password properties: client_id: type: string description: Your unique client identifier (a UUID), provided by Kira. example: 00000000-0001-0000-0000-001122334455 password: type: string description: >- The password for your integration credentials, provided by Kira. examples: get-access-token: summary: Get Access Token value: client_id: '{{client_id}}' password: '{{password}}' responses: '200': description: Access token issued. content: application/json: schema: type: object properties: message: type: string data: $ref: '#/components/schemas/AuthResponse' required: - message - data example: message: Auth token data: access_token: eyJ… expires_in: 3600 token_type: Bearer '400': description: Validation error. content: application/json: schema: $ref: '#/components/schemas/ValidationErrorResponse' '401': description: >- Unauthorized — unknown or invalid credentials (`{ "code": "unauthorized", "message": "..." }`). Note: the sandbox currently returns a `500` for an unknown `client_id` instead of this `401` (fix pending) — treat any non-`200` from `/auth` as an authentication failure. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - apiKeyAuth: [] components: schemas: AuthResponse: description: >- The token payload. In the `POST /auth` `200` response this object arrives **nested under `data`** in the `{ message, data }` envelope — read `data.access_token`, not a top-level `access_token`. type: object properties: access_token: type: string token_type: type: string expires_in: type: number required: - access_token - token_type - expires_in ValidationErrorResponse: type: object description: >- Validation / request error. The body shape is **not uniform** across the API — it varies by endpoint and by which validation layer rejects the request. The fields below are the union of what may appear; treat them all as optional. Observed shapes include `{ code, message }`, `{ code, message, errors[] }`, `{ code, error, details[] }`, `{ error, details[] }`, and a nested `{ error: { code, message, details } }`. Always branch on the HTTP status, not on a fixed body shape. properties: code: type: string message: type: string error: type: - string - object description: >- A short error label (e.g. `"Invalid data"`), or on some endpoints a nested `{ code, message, details }` object. errors: type: array items: type: object properties: field: type: string message: type: string required: - field - message details: type: - array - object description: >- Per-issue detail. Shape varies by endpoint — typically an array of `{ message }` or `{ path, message, code }`, occasionally an object. ErrorResponse: type: object properties: message: type: string code: type: string statusCode: type: number error: type: string timestamp: type: string path: type: string details: {} required: - message securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT description: Access token from `POST /auth` (the `data.access_token` value). apiKeyAuth: type: apiKey in: header name: x-api-key description: API key issued by Kira. Required on every request, including `/auth`. ````