> ## 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 a capability request > Read one capability request, with where it stands. ## OpenAPI ````yaml /openapi/kira-api.2026-04-14.json get /v1/capability-requests/{request_id} 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 except the token call needs a bearer access token (see Authentication). Pin your account to the recommended version before integrating (see [Versioning](/using-the-api/versioning)). 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: [] tags: - name: Authentication - name: Versioning - name: Users - name: Virtual Accounts - name: Recipients - name: Quotations - name: Payouts - name: Ultimate Payors - name: Capabilities - name: Reference - name: RFIs paths: /v1/capability-requests/{request_id}: get: tags: - Capabilities summary: Get a capability request description: Read one capability request, with where it stands. operationId: get_v1-capability-requests-request-id parameters: - in: path name: request_id required: true schema: type: string format: uuid description: The `id` the request was opened with. - in: header name: X-Api-Version required: false description: >- Version applied to this request. It wins over your account's pinned version — see [Versioning](/using-the-api/versioning). schema: type: string example: '2026-04-14' responses: '200': description: The request. content: application/json: schema: $ref: '#/components/schemas/CapabilityRequest' examples: approved: summary: Approved, and the sub-client holds the capability value: id: 5d2e8f14-7a3b-4c6d-9e1f-2a3b4c5d6e7f user_id: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee capability: pobo status: approved requirements_version: 850f14 evidence: answers_sha256: >- 3f9a1c7e0b5d2a8f4e6c1b9d7a3e5f2c8b0d4a6e1f3c5b7d9a2e4f6c8b0d1a3e document_count: 2 review: answer: GREEN grant: event_uuid: 9c4b2a1d-3e5f-4a6b-8c7d-0e1f2a3b4c5d status: granted created_at: '2026-10-17T09:41:05.120Z' created_at: '2026-10-15T14:03:22.418Z' submitted_at: '2026-10-16T18:20:11.004Z' decided_at: '2026-10-17T09:41:05.120Z' sent_back: summary: Sent back to the sub-client to complete value: id: 5d2e8f14-7a3b-4c6d-9e1f-2a3b4c5d6e7f user_id: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee capability: pobo status: requested requirements_version: 850f14 verification_link: https://identity.example.com/websdk/p/aGVsbG8tdGhlcmU verification_link_expires_at: '2026-11-16T10:12:40.771Z' evidence: answers_sha256: >- 3f9a1c7e0b5d2a8f4e6c1b9d7a3e5f2c8b0d4a6e1f3c5b7d9a2e4f6c8b0d1a3e document_count: 1 review: answer: RED reject_type: RETRY labels: - INCOMPLETE_DOCUMENT created_at: '2026-10-15T14:03:22.418Z' submitted_at: '2026-10-16T18:20:11.004Z' decided_at: null '400': description: >- `request_id` is not a UUID. The id is checked before the lookup, so a malformed one is a `400`, never a `404`. This body has `error` and `details[]`, and no `code`. content: application/json: schema: $ref: '#/components/schemas/ValidationErrorResponse' example: error: Invalid request data details: - path: request_id message: Invalid uuid code: invalid_string '401': description: >- No valid bearer token came with the request. Get one from [Get access token](/api-reference/authentication/get-access-token) and send it as `Authorization: Bearer `. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: code: invalid_request message: >- The request was not authenticated. Request a token at POST /auth with your Client ID and your API key, then send it as Authorization: Bearer . '404': description: >- No request of yours has that id. The same body comes back whether the id does not exist or the request belongs to another client. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: statusCode: 404 error: Not Found message: Not found timestamp: '2026-10-15T14:03:22.418Z' path: /v1/capability-requests/5d2e8f14-7a3b-4c6d-9e1f-2a3b4c5d6e7f code: not_found '500': description: >- Something failed on our side. Retry, and if it keeps happening contact your Kira contact with the time of the call. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: status: error message: Internal server error security: - bearerAuth: [] apiKeyAuth: [] servers: - url: https://api.balampay.com/sandbox description: Sandbox - url: https://api.balampay.com description: Production components: schemas: CapabilityRequest: type: object description: >- A request that a sub-client be enabled for a capability — see [The capability request object](/reference/capabilities/the-capability-request-object). properties: id: type: string format: uuid description: The request's identifier. user_id: type: string format: uuid description: The sub-client the request is for. capability: type: string description: >- The capability requested — see [Values](/reference/capabilities/values#capability). status: type: string description: >- Where the request stands. Available options: `requested`, `submitted`, `approved`, `rejected`, `cancelled` — see [Values](/reference/capabilities/values#request-status). requirements_version: type: string description: >- Identifies the list of requirements the request was opened against. It changes when that list changes. verification_link: type: string format: uri description: |- The link where the sub-client answers the requirements. Only while `status` is `requested`. verification_link_expires_at: type: - string - 'null' format: date-time description: >- When `verification_link` stops working, ISO 8601. Request the capability again with [Request a capability](/api-reference/capabilities/request-a-capability) for a fresh link. evidence: type: object description: >- What the sub-client sent, once Kira has kept a copy of it. The answers and files themselves are never returned. properties: answers_sha256: type: - string - 'null' description: SHA-256 of the answers, to tell one submission from another. document_count: type: integer description: How many files the sub-client attached. review: type: object description: >- The latest review outcome. Absent until compliance has reviewed the request. properties: answer: type: string description: >- Available options: `GREEN`, `RED` — see [Values](/reference/capabilities/values#review-answer). reject_type: type: string description: >- On a `RED` answer. Available options: `RETRY`, `FINAL` — see [Values](/reference/capabilities/values#review-reject_type). labels: type: array description: Codes naming what the review found, when it named any. items: type: string grant: type: object description: The capability the approval granted. Only on an `approved` request. properties: event_uuid: type: string format: uuid description: The grant's identifier. status: type: string description: >- Whether the sub-client still holds the capability. Available options: `granted`, `revoked` — see [Values](/reference/capabilities/values#grant-status). created_at: type: string format: date-time description: When the grant reached this status, ISO 8601. cancel_reason: type: string description: >- Why the request was cancelled. Only on a `cancelled` request — see [Values](/reference/capabilities/values#cancel_reason). created_at: type: string format: date-time description: When the request was opened, ISO 8601. submitted_at: type: - string - 'null' format: date-time description: When the sub-client sent its answers, ISO 8601. `null` until then. decided_at: type: - string - 'null' format: date-time description: >- When the request was approved or rejected, ISO 8601. `null` until then. 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: >- The `data.access_token` value from [Get access token](/api-reference/authentication/get-access-token). ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.