> ## 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. # Pin account to a version > Pin the authenticated account's default API version to `target_version`. Pins are **forward-only**: you can move to a newer version, but a `target_version` older than your current pin is rejected with `400`. An unsupported `target_version` also returns `400`. The call is idempotent — pinning to the version you are already on is a safe no-op. On success the API returns `200` with your `previous_version` and `current_version`. Once pinned, the `X-Api-Version` header becomes optional on later requests (your pin is the default), though the header still wins per-request when sent. See the [Versioning](/guides/versioning) guide for the full resolution order. {/* version-stamp:start — generated by scripts/stamp-versions.ts, do not edit */} Stable since **2025-01-01** — unchanged in **2026-06-01**. {/* version-stamp:end */} ## OpenAPI ````yaml /openapi/kira-api.2026-06-01.json post /v1/versioning/upgrade openapi: 3.1.0 info: title: Kira API version: '2026-06-01' 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 - name: RFIs paths: /v1/versioning/upgrade: post: tags: - Versioning summary: Pin account to a version description: >- Pin the authenticated account's default API version to `target_version`. Pins are **forward-only**: you can move to a newer version, but a `target_version` older than your current pin is rejected with `400`. An unsupported `target_version` also returns `400`. The call is idempotent — pinning to the version you are already on is a safe no-op. On success the API returns `200` with your `previous_version` and `current_version`. Once pinned, the `X-Api-Version` header becomes optional on later requests (your pin is the default), though the header still wins per-request when sent. See the [Versioning](/guides/versioning) guide for the full resolution order. operationId: post_v1-versioning-upgrade parameters: - in: header name: X-Api-Version required: false description: >- Optional. The date-versioned API version to apply for this request (e.g. `2026-04-14`). When sent it always wins, even over your pinned account default. When omitted, the API uses your account's pinned version if set, otherwise a baseline default. schema: type: string example: '2026-06-01' requestBody: required: true content: application/json: schema: type: object required: - target_version properties: target_version: type: string description: >- The date-versioned API version to pin your account to (e.g. `2026-04-14`). Must be a supported version and not older than your current pin — downgrades and unknown versions return `400`. example: '2026-06-01' examples: pin-account-to-v2026-06-01: summary: Pin Account to v2026-06-01 value: target_version: '2026-06-01' responses: '200': description: >- Account pinned. Returns your version pin before and after the upgrade. content: application/json: schema: type: object required: - previous_version - current_version properties: previous_version: type: string description: The version your account was pinned to before this call. example: '2025-01-01' current_version: type: string description: >- The version your account is now pinned to (equals `target_version`). example: '2026-06-01' '400': description: Validation error. content: application/json: schema: $ref: '#/components/schemas/ValidationErrorResponse' '401': description: Unauthorized. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: The authenticated client row was not found. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - bearerAuth: [] apiKeyAuth: [] components: schemas: 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`. ````