> ## 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 an RFI > Retrieve a single RFI by its UUID, with its items nested. The RFI must belong to you. {/* 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 get /v1/rfis/{rfi_id} 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/rfis/{rfi_id}: get: tags: - RFIs summary: Get an RFI description: >- Retrieve a single RFI by its UUID, with its items nested. The RFI must belong to you. operationId: get_v1-rfis-rfi-id parameters: - in: path name: rfi_id required: true schema: type: string format: uuid description: RFI UUID. - 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' responses: '200': description: Success. content: application/json: schema: $ref: '#/components/schemas/Rfi' '400': description: >- Malformed id — `rfi_id` is not a valid UUID. Ids are format-validated before lookup, so a syntactically invalid id returns `400` (not `404`). content: application/json: schema: $ref: '#/components/schemas/ValidationErrorResponse' '401': description: Unauthorized. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: >- Not found — belongs to another client, or is `withdrawn` (a withdrawn RFI 404s; it is never a visible empty row). content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - bearerAuth: [] apiKeyAuth: [] components: schemas: Rfi: type: object description: >- A request for information — one need, with its items nested. `client_uuid` (tenancy — you already are the client) and `created_by` / `returned_by` (which Kira analyst acted) are never echoed. required: - rfi_id - user_id - status - due_at - blocking - resolution_reason - created_at - first_answered_at - updated_at - closed_at - items properties: rfi_id: type: string format: uuid user_id: type: string format: uuid description: The subclient this RFI is about. status: type: string enum: - pending - answered - resolved - not_resolved description: >- `pending` — it's your turn (unanswered items remain, or one was returned). `answered` — you answered everything; Kira is reviewing. `resolved` — Kira confirmed the need satisfied, terminal; always an act on the whole RFI, never inferred from its items. `not_resolved` — closed without resolving, terminal; see `resolution_reason`. A `withdrawn` RFI never appears here — it 404s instead. due_at: type: string format: date-time blocking: oneOf: - $ref: '#/components/schemas/RfiBlockingTransfer' - $ref: '#/components/schemas/RfiBlockingDeposit' - type: 'null' description: >- What this RFI is anchored to, or `null` when it's about the subclient directly (not a specific transaction). There is no virtual-account or capability anchor — an RFI never names which account is blocked. resolution_reason: type: - string - 'null' enum: - expired - rejected - null description: Set only when `status` is `not_resolved`. created_at: type: string format: date-time first_answered_at: type: - string - 'null' format: date-time description: >- When you first handed back a response. Measures the hand-off to Kira, not when your subclient actually answered — the gap between the two is invisible to this API. updated_at: type: - string - 'null' format: date-time description: >- When this need was last answered. Moves on every answer round; a return that walks `status` back to `pending` doesn't touch it. closed_at: type: - string - 'null' format: date-time description: >- Set for all three closed outcomes — `resolved`, `not_resolved`, `withdrawn` — dating whichever occurred. items: type: array items: $ref: '#/components/schemas/RfiItem' 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 RfiBlockingTransfer: type: object required: - type - transfer_uuid properties: type: type: string enum: - transfer transfer_uuid: type: string format: uuid RfiBlockingDeposit: type: object required: - type - virtual_account_deposit_uuid properties: type: type: string enum: - virtual_account_deposit virtual_account_deposit_uuid: type: string format: uuid RfiItem: type: object description: >- One thing being asked for. The addressable unit of an RFI — a `PATCH` or a document upload always names an `item_id`, never the parent RFI. required: - item_id - ordinal - prompt - answer_type - answer_spec - target_key - status - answer_value - documents - review_note - updated_at - returned_at properties: item_id: type: string format: uuid ordinal: type: integer description: Display order within the RFI. prompt: type: string description: What is being asked, in prose. answer_type: type: string enum: - text_long - text_short - number - date - boolean - choice - identifier - document description: >- The shape the answer must take. Closed by a database `CHECK`, not just this schema. answer_spec: type: object additionalProperties: true description: >- Configuration for `answer_type`, closed per type — the full set of keys the item will validate an answer against, not a suggestion. A new question shape is data here, never a contract change. Only two shapes are contract-fixed today: `document` (`mime_types: string[]`, `max_files: integer`) and `identifier` (`format: string`, e.g. `"ein"`). The `answer_spec` shape for `text_long` / `text_short` / `number` / `date` / `boolean` / `choice` is implementation-defined and not yet fixed by this contract — confirm before building against it. example: mime_types: - application/pdf max_files: 5 target_key: type: - string - 'null' description: >- The named subclient field this answer writes on acceptance (e.g. `ein`), or `null` when the answer lives only on this item. status: type: string enum: - pending - answered description: >- `pending` — awaiting your answer, whether never answered or returned for a fix (see `review_note`). `answered` — submitted, in review. An item carries no terminal state of its own — whether the RFI as a whole is satisfied is `rfi.status`, not this column. answer_value: type: - string - number - boolean - 'null' description: >- The submitted answer, in the shape `answer_type` expects: a JSON string for `text_short` / `text_long` / `date` / `choice` / `identifier`, a JSON number for `number`, a JSON boolean for `boolean`. `null` only for a `document` item, whose answer lives in `documents[]` instead. documents: type: array items: $ref: '#/components/schemas/RfiDocument' description: Always present; empty unless `answer_type` is `document`. review_note: type: - string - 'null' description: >- Why the analyst returned this item for another answer. Set while `status` is `pending` as the result of a return; cleared the next time the item is answered. updated_at: type: - string - 'null' format: date-time description: >- When this item was last answered. Moves on every round, whether or not it changes the item's status. returned_at: type: - string - 'null' format: date-time description: >- When an analyst last sent this item back for another answer. Null if it has never been returned — including while it's under review, since a pass-through review stamps nothing here. RfiDocument: type: object description: >- A file attached to a `document` item's response. `uploaded_by` is never echoed here: it always resolves to your own API key (the subclient never calls this API directly), so a field that always reads back "you" carries nothing for the reader — the same reasoning the contract applies to `client_uuid`. required: - document_id - file_name - mime_type - size_bytes - uploaded_at properties: document_id: type: string format: uuid file_name: type: string description: >- The name the file was uploaded under, sanitized. This is the name it downloads as — the internal storage path is never exposed. example: january.pdf mime_type: type: string example: application/pdf size_bytes: type: integer checksum: type: string description: Content hash of the uploaded file. uploaded_at: type: string format: date-time 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`. ````