> ## 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 recipient

> Retrieve a single recipient (payout destination) you own, by its UUID. The response is the bare recipient object (no `{ message, data }` wrapper).

-   `type` — `"individual"` or `"business"`. Personal name/contact fields are omitted entirely when empty (rather than returned as `null`).
-   `address` — polymorphic: a structured object `{ street_name, city, state, postal_code, country }` when a city is on file, otherwise a plain string, otherwise omitted. This is the recipient's own address, distinct from the bank address inside `account_details`.
-   `account_type` — the rail code (uppercase), e.g. `ACH`, `WIRE`, `WALLET`.
-   `account_details` — a union whose fields depend on `account_type`. For example: `WALLET` → `{ token, network, address }`; `ACH` → `{ routing_number, account_number, type, bank_name, bank_address }`; `WIRE` → adds `swift_code` and a structured `bank_address`. `doc_type` values are normalized to lowercase.
-   `metadata` — your attached key/value map (defaults to `{}`).

**Errors:** a recipient that does not exist _or_ belongs to another client both return `404`; a malformed id returns `400`.

{/* version-stamp:start — generated by scripts/stamp-versions.ts, do not edit */}

<Info>Stable since **2025-01-01** — unchanged in **2026-04-14**.</Info>

{/* version-stamp:end */}


## OpenAPI

````yaml /openapi/kira-api.2026-04-14.json get /v1/recipients/{recipient_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 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:
  /v1/recipients/{recipient_id}:
    get:
      tags:
        - Recipients
      summary: Get a recipient
      description: >-
        Retrieve a single recipient (payout destination) you own, by its UUID.
        The response is the bare recipient object (no `{ message, data }`
        wrapper).


        -   `type` — `"individual"` or `"business"`. Personal name/contact
        fields are omitted entirely when empty (rather than returned as `null`).

        -   `address` — polymorphic: a structured object `{ street_name, city,
        state, postal_code, country }` when a city is on file, otherwise a plain
        string, otherwise omitted. This is the recipient's own address, distinct
        from the bank address inside `account_details`.

        -   `account_type` — the rail code (uppercase), e.g. `ACH`, `WIRE`,
        `WALLET`.

        -   `account_details` — a union whose fields depend on `account_type`.
        For example: `WALLET` → `{ token, network, address }`; `ACH` → `{
        routing_number, account_number, type, bank_name, bank_address }`; `WIRE`
        → adds `swift_code` and a structured `bank_address`. `doc_type` values
        are normalized to lowercase.

        -   `metadata` — your attached key/value map (defaults to `{}`).


        **Errors:** a recipient that does not exist _or_ belongs to another
        client both return `404`; a malformed id returns `400`.
      operationId: get_v1-recipients-recipient-id
      parameters:
        - in: path
          name: recipient_id
          required: true
          schema:
            type: string
            format: uuid
          description: Recipient 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-04-14'
      responses:
        '200':
          description: Success.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RecipientResponse'
        '400':
          description: >-
            Malformed id — `recipient_id` is not a valid UUID. Ids are
            format-validated **before** lookup, so a syntactically invalid id
            returns `400` (not `404`); `404` is reserved for well-formed ids
            that do not exist.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ValidationErrorResponse'
              example:
                error: Invalid request data
                details:
                  - path: recipientId
                    message: Invalid recipient ID format
                    code: invalid_string
        '401':
          description: Unauthorized.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '404':
          description: Not found.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
      security:
        - bearerAuth: []
          apiKeyAuth: []
components:
  schemas:
    RecipientResponse:
      type: object
      properties:
        recipient_id:
          type: string
          format: uuid
          description: >-
            The recipient's UUID. **Recipients are the naming outlier:** this
            field is `recipient_id`, not the `id` used by the user and
            virtual-account resources — parse it by name.
        type:
          type: string
          description: >-
            `individual` or `business`. Determines whether the holder is
            `first_name`/`last_name` or `company_name`.
        first_name:
          type: string
          description: >-
            Given name (individual recipients). ASCII-normalized on write —
            accents are transliterated and disallowed characters stripped, so
            the stored value may differ from what you sent.
        middle_name:
          type: string
          description: >-
            Middle name (individual recipients), when provided. ASCII-normalized
            on write.
        last_name:
          type: string
          description: Family name (individual recipients). ASCII-normalized on write.
        company_name:
          type: string
          description: Legal company name (business recipients).
        phone:
          type: string
          description: Contact phone for the recipient, when provided.
        email:
          type: string
          description: Contact email for the recipient, when provided.
        address:
          description: >-
            The **recipient's own** address (string or structured object). This
            is distinct from the recipient bank's address, which lives in
            `account_details.bank_address`.
          anyOf:
            - type: string
            - type: object
              properties: {}
        account_type:
          type: string
          description: >-
            The payout rail: `ACH`, `WIRE`, or `WALLET`. Mirrors the
            `account.account_type` discriminator sent at create time.
        account_details:
          type: object
          description: >-
            Rail-specific bank or wallet details, mirroring the `account` object
            sent at create time. **Read-after-write caveats:** for `WIRE`,
            `bank_address.state` and `bank_address.postal_code` are silently
            returned as empty strings even when you sent them; and a
            `holder_name` is never stored (the holder is taken from
            `first_name`/`last_name` or `company_name`).
          properties: {}
        created_ts:
          type: string
          description: >-
            Creation timestamp. **Outlier format:** recipients use `created_ts`
            (not the ISO-8601 `created_at` used by user and virtual-account
            resources) — do not assume it round-trips as ISO 8601.
        updated_ts:
          type: string
          description: >-
            Last-update timestamp. Like `created_ts`, this is the
            recipient-specific `*_ts` field rather than the `updated_at` used
            elsewhere.
        metadata:
          type: object
          description: Your own key/value string pairs attached to the recipient.
          additionalProperties:
            type: string
      required:
        - recipient_id
        - type
        - account_type
        - account_details
        - created_ts
        - updated_ts
    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`.

````