> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Record a client settlement-deposit ack

> Records the client's STR deposit ack for a relayed position notify and drives the settlement instruction to ACKED for a SENT deposit (from PENDING or NOTIFIED) (the client owns the STR connection; the SLC emits NO LDL0022). A FAILED result is recorded but leaves the instruction unchanged so the deposit can be re-driven. Synchronous and definitive. Idempotent via the Idempotency-Key header (a retry carrying the same key replays the stored response). result must be SENT or FAILED (coded 400 otherwise). RBAC: funding:write; tenant is always derived from the validated request identity, never the payload.



## OpenAPI

````yaml en/openapi/v3-current/slc.yaml post /v1/funding/settlement-instructions/{instructionId}/ack
openapi: 3.1.0
info:
  description: >-
    API for Lerian SLC — the participant-side rail that connects the institution
    to Núclea's SLC deferred-net card settlement. It covers settlement-operation
    intake and lifecycle, clearing positions, the participant and arrangement
    registry, generated reports, embedded XSD schema introspection, transmission
    recovery and connectivity to Núclea, BYOK Model-A signing-key import, and
    tenant-scoped webhooks.
  title: Lerian SLC API
  version: 1.0.0
servers:
  - url: https://slc.sandbox.lerian.net
security:
  - BearerAuth: []
tags:
  - description: >-
      Settlement operation lifecycle — create, list, query, and control the
      NUliquid-tracked card operations (NUliquid = the 21-position id Núclea
      assigns each accepted operation) through the state machine.
    name: Operations
  - description: >-
      Participant catalog — the acquirers, sub-acquirers, IF Domicílio (bank
      where the merchant receives its sales), and settlement FIs (financial
      institutions) that take part in card settlement.
    name: Participants
  - description: >-
      Card arrangements (bandeira/scheme configurations, e.g. Visa/Master/Elo)
      attached to a participant.
    name: Arrangements
  - description: >-
      Regulated transport orchestration to Núclea/SILOC (the private card
      clearing house that operates the SILOC settlement system) — dispatch,
      recovery, retransmission, and connectivity testing over managed
      file-transfer, message-broker, and REST.
    name: Connectivity
  - description: >-
      Multilateral netting clearing positions — the net amount each participant
      settles per STR cycle (STR = Banco Central reserves-transfer system).
    name: Clearing
  - description: >-
      SaaS BYOK (Bring Your Own Key) signing-key provisioning — import
      parameters and register the client's ICP-Brasil A1 (Brazilian PKI server
      certificate, 1-year validity) certificate material used to sign ASLC
      files; the private key never leaves the client's HSM/KMS/Vault.
    name: SigningKey
  - description: >-
      ASLC file intake and status — passthrough submission and processing status
      of the official Núclea card-settlement XML files (ASLC = Arquivo do
      Sistema de Liquidação de Cartões).
    name: Files
  - description: >-
      Read-only introspection of the embedded Núclea ASLC/RSFN (National
      Financial System Network) XSD schemas used to validate outbound and
      inbound messages.
    name: XSD Schemas
  - description: Read-only regulatory, compliance, and operational settlement reports.
    name: Reports
  - description: >-
      Outbound business-event webhook subscriptions and delivery management for
      consumers (Midaz, client ledgers, Cabine — all optional).
    name: Webhooks
  - description: >-
      Administrative operations — hot-reloadable runtime configuration,
      dead-letter-queue inspection/replay, and outbox redispatch.
    name: Admin
paths:
  /v1/funding/settlement-instructions/{instructionId}/ack:
    post:
      tags:
        - Funding
      summary: Record a client settlement-deposit ack
      description: >-
        Records the client's STR deposit ack for a relayed position notify and
        drives the settlement instruction to ACKED for a SENT deposit (from
        PENDING or NOTIFIED) (the client owns the STR connection; the SLC emits
        NO LDL0022). A FAILED result is recorded but leaves the instruction
        unchanged so the deposit can be re-driven. Synchronous and definitive.
        Idempotent via the Idempotency-Key header (a retry carrying the same key
        replays the stored response). result must be SENT or FAILED (coded 400
        otherwise). RBAC: funding:write; tenant is always derived from the
        validated request identity, never the payload.
      operationId: recordFundingAck
      parameters:
        - description: Settlement instruction id (UUID).
          in: path
          name: instructionId
          required: true
          schema:
            description: Settlement instruction id (UUID).
            examples:
              - 018f8a3e-4b2c-7c1a-9e5d-2f6a1b3c4d5e
            type: string
        - description: >-
            Idempotency key for safe retries; a replay carrying the same key
            returns the stored response instead of appending a duplicate audit
            row (scoped to tenant + this instruction's ack route).
          in: header
          name: Idempotency-Key
          schema:
            description: >-
              Idempotency key for safe retries; a replay carrying the same key
              returns the stored response instead of appending a duplicate audit
              row (scoped to tenant + this instruction's ack route).
            type: string
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/RecordAckRequest'
        required: true
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RecordAckResponse'
          description: OK
        default:
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/Detail'
          description: Error
components:
  schemas:
    RecordAckRequest:
      additionalProperties: false
      properties:
        ackedAt:
          description: When the client reported the ack (RFC3339). Omitted stores NULL.
          examples:
            - '2026-06-28T11:00:00Z'
          type: string
        amountCents:
          description: Deposited amount in cents.
          examples:
            - 5011
          format: int64
          type: integer
        errorDetail:
          description: Failure reason when result is FAILED.
          examples:
            - insufficient reserves
          type: string
        ldl0022Ref:
          description: >-
            Client reference to its LDL0022 (IF->STR); recorded for audit,
            outside the SLC.
          examples:
            - LDL0022-2026-06-28-000123
          type: string
        result:
          description: >-
            Client deposit result: SENT (deposited) or FAILED (could not).
            Case-insensitive — the value is upper-cased before validation, so
            "sent"/"failed" are accepted (intentionally lenient).
          examples:
            - SENT
          type: string
      required:
        - result
      type: object
    RecordAckResponse:
      additionalProperties: false
      properties:
        instructionId:
          description: The settlement instruction id the ack was recorded against.
          type: string
        result:
          description: The accepted ack result (SENT/FAILED), upper-cased.
          type: string
        state:
          description: >-
            The resulting instruction state — present ONLY when this ack drove
            the transition (always ACKED). Omitted when transitioned is false;
            do not infer a state from the result.
          type: string
        transitioned:
          description: >-
            Whether this ack drove the instruction to ACKED. True only for a
            SENT ack that matched an instruction in PENDING or NOTIFIED; false
            for FAILED and for a SENT ack against an instruction not in
            PENDING/NOTIFIED (already acked/settled). The ack is recorded either
            way.
          type: boolean
      required:
        - instructionId
        - result
        - transitioned
      type: object
    Detail:
      additionalProperties: false
      properties:
        code:
          description: >-
            Stable, machine-readable domain error code scoped to the emitting
            service (format: <SERVICE>-NNNN).
          examples:
            - ERR-0001
          type: string
        detail:
          description: >-
            A human-readable explanation specific to this occurrence of the
            problem.
          examples:
            - Property foo is required but is missing.
          type: string
        errors:
          description: Optional list of individual error details
          items:
            $ref: '#/components/schemas/ErrorDetail'
          type:
            - array
            - 'null'
        instance:
          description: >-
            A URI reference that identifies the specific occurrence of the
            problem.
          examples:
            - https://example.com/error-log/abc123
          format: uri
          type: string
        status:
          description: HTTP status code
          examples:
            - 400
          format: int64
          type: integer
        title:
          description: >-
            A short, human-readable summary of the problem type. This value
            should not change between occurrences of the error.
          examples:
            - Bad Request
          type: string
        type:
          default: about:blank
          description: A URI reference to human-readable documentation for the error.
          examples:
            - https://example.com/errors/example
          format: uri
          type: string
      type: object
    ErrorDetail:
      additionalProperties: false
      properties:
        location:
          description: >-
            Where the error occurred, e.g. 'body.items[3].tags' or
            'path.thing-id'
          type: string
        message:
          description: Error message text
          type: string
        value:
          description: The value at the given location
      type: object
  securitySchemes:
    BearerAuth:
      bearerFormat: JWT
      description: JWT bearer token issued by the identity provider.
      scheme: bearer
      type: http

````