> ## 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 what was established about an unresolved cancellation repasse > Records the outcome an operator ESTABLISHED for ASLC063/067 repasses whose delivery this service could not determine on its own. RBAC: connectivity:admin. It is the ONLY way to clear an unresolved repasse intention, and each clearing is one-way. CONFIRMED means you established the file DID reach Núclea: the repasse's duty is discharged and the (operationId, aslcType) pair STAYS blocked, because relaying again would duplicate a regulatory notification to the acquirer. ABANDONED means you established it NEVER reached Núclea: the pair is returned to a relayable state, while the burnt control number and the attempt count survive on the row so the attempt budget still sees what this repasse has spent. IN_FLIGHT is REFUSED as an outcome with 400 — that state belongs to the relay itself, which writes it alongside a fresh control number and a charged attempt, so re-arming a repasse through this verb would unblock a submission whose outcome is unknown and charge nothing for it. reason is ALWAYS required and is logged at ERROR with the targets: it is the audit record of a human overriding an automated refusal on a regulatory rail. There is no scope-wide form: each intention records a finding about a DIFFERENT file at Núclea, and only the caller knows which ones they checked — the same posture POST /v1/connectivity/unpark takes. Enumerate the targets with GET /v1/connectivity/cancellation-relay-intents. Idempotent: re-running reports the already-recorded intentions as not_in_flight and rewrites nothing, so a repeat can never overturn a finding. Per-target results are resolved / not_in_flight / not_found. It transmits nothing, drives no operation transition and emits no business event. ## OpenAPI ````yaml /en/openapi/v3-current/slc.yaml post /v1/connectivity/cancellation-relay-intents/resolve openapi: 3.1.0 info: description: >- API for Lerian SLC — the participant-side rail that connects the institution to Núclea's SLC card settlement. 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's SLC — 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 server-type certificate material used to sign ASLC files (RSA, at least 2048 bits, and valid at the moment of import — all three are enforced); the SLC never receives the private key in cleartext. 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 (client ledgers — optional). name: Webhooks - description: >- Administrative operations — hot-reloadable runtime configuration, dead-letter-queue inspection/replay, and outbox redispatch. name: Admin paths: /v1/connectivity/cancellation-relay-intents/resolve: post: tags: - Connectivity summary: Record what was established about an unresolved cancellation repasse description: >- Records the outcome an operator ESTABLISHED for ASLC063/067 repasses whose delivery this service could not determine on its own. RBAC: connectivity:admin. It is the ONLY way to clear an unresolved repasse intention, and each clearing is one-way. CONFIRMED means you established the file DID reach Núclea: the repasse's duty is discharged and the (operationId, aslcType) pair STAYS blocked, because relaying again would duplicate a regulatory notification to the acquirer. ABANDONED means you established it NEVER reached Núclea: the pair is returned to a relayable state, while the burnt control number and the attempt count survive on the row so the attempt budget still sees what this repasse has spent. IN_FLIGHT is REFUSED as an outcome with 400 — that state belongs to the relay itself, which writes it alongside a fresh control number and a charged attempt, so re-arming a repasse through this verb would unblock a submission whose outcome is unknown and charge nothing for it. reason is ALWAYS required and is logged at ERROR with the targets: it is the audit record of a human overriding an automated refusal on a regulatory rail. There is no scope-wide form: each intention records a finding about a DIFFERENT file at Núclea, and only the caller knows which ones they checked — the same posture POST /v1/connectivity/unpark takes. Enumerate the targets with GET /v1/connectivity/cancellation-relay-intents. Idempotent: re-running reports the already-recorded intentions as not_in_flight and rewrites nothing, so a repeat can never overturn a finding. Per-target results are resolved / not_in_flight / not_found. It transmits nothing, drives no operation transition and emits no business event. operationId: resolveCancellationRelayIntents requestBody: content: application/json: schema: $ref: '#/components/schemas/ResolveCancellationRelayIntentsRequest' required: true responses: '200': content: application/json: schema: $ref: '#/components/schemas/ResolveCancellationRelayIntentsResponse' description: OK '422': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Unprocessable Entity '500': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Internal Server Error '501': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: >- Not Implemented: this capability is not part of this deployment. Operations are registered unconditionally so the published contract is identical across deploy shapes; when the capability behind one did not compose here (authentication disabled, no database, no outbound transport, or the feature switched off) it answers this coded SLC-0012 problem. It is definitive for this deployment: retrying does not help, and the `detail` is deliberately scrubbed (any status >= 500 is). default: content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Error components: schemas: ResolveCancellationRelayIntentsRequest: additionalProperties: false properties: intents: description: >- The intentions to resolve, enumerated with GET /v1/connectivity/cancellation-relay-intents. 1..500 entries; repeats of the same (operationId, aslcType) pair are collapsed. items: $ref: '#/components/schemas/RelayIntentTargetRequest' maxItems: 500 minItems: 1 type: - array - 'null' outcome: description: >- The finding, one of CONFIRMED or ABANDONED. CONFIRMED = you established the file DID reach Núclea: the repasse's duty is discharged and the pair stays blocked, because relaying again would duplicate a regulatory notification. ABANDONED = you established it NEVER reached Núclea: the pair is returned to a relayable state, and the burnt control number plus the attempt count survive on the row. enum: - CONFIRMED - ABANDONED examples: - ABANDONED type: string reason: description: >- How the finding was established. ALWAYS required: this is the audit record of a human overriding an automated refusal on a regulatory rail, and both findings are consequential — a wrong CONFIRMED drops the acquirer's notification for good, a wrong ABANDONED lets a second one be submitted. It is logged at ERROR with the targets. examples: - >- Núclea support ticket 48210: control number 2026052800019 was never received. maxLength: 500 minLength: 1 type: string required: - outcome - reason - intents type: object ResolveCancellationRelayIntentsResponse: additionalProperties: false properties: action: description: Admin action that was executed. examples: - resolve-cancellation-relay-intent type: string items: description: Per-target detail, in the request's (deduplicated) order. items: $ref: '#/components/schemas/RelayIntentResolutionResponse' type: array outcome: description: The finding that was recorded. enum: - CONFIRMED - ABANDONED examples: - ABANDONED type: string requested: description: Distinct (operationId, aslcType) pairs named in the request. examples: - 3 format: int64 type: integer resolved: description: >- Intentions whose guarded UPDATE actually matched; these now carry the finding. examples: - 2 format: int64 type: integer skipped: description: >- Pairs with no intention, or whose intention was no longer unresolved. examples: - 1 format: int64 type: integer required: - action - outcome - requested - resolved - skipped - items type: object Detail: additionalProperties: false properties: code: description: >- Stable, machine-readable domain error code scoped to the emitting service (format: -NNNN). type: string correlationId: description: Request-scoped correlation identifier echoing X-Request-ID. examples: - req-7a3f9c2e 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 upstream: $ref: '#/components/schemas/Upstream' description: >- RFC 9457 extension member: the error a proxied third-party provider reported. Absent unless the emitting service explicitly surfaced one. required: - correlationId type: object RelayIntentTargetRequest: additionalProperties: false properties: aslcType: description: >- Relay family, exactly as the listing reports it: ASLC063 (credit, OP107 v21.0 §8.1.1.2) or ASLC067 (debit, §8.1.2.2). enum: - ASLC063 - ASLC067 examples: - ASLC063 type: string operationId: description: Id of the ORIGINAL movement, exactly as the listing reports it. examples: - 018f8a3e-4b2c-7c1a-9e5d-2f6a1b3c4d5e format: uuid type: string required: - operationId - aslcType type: object RelayIntentResolutionResponse: additionalProperties: false properties: aslcType: description: Echoes the target's relay family. enum: - ASLC063 - ASLC067 examples: - ASLC063 type: string controlNumber: description: >- The burnt NumCtrlEmis carried by the row, echoed so your audit record names the value you reconciled. Absent when there is no row. examples: - '2026052800019' type: string operationId: description: >- Echoes the target, so outcomes can be correlated without relying on array order. examples: - 018f8a3e-4b2c-7c1a-9e5d-2f6a1b3c4d5e type: string result: description: >- resolved = the intention was unresolved and now carries your finding. not_in_flight = it was already reconciled (state says which way), or another caller won the race (state is then absent). not_found = there is no intention for that pair at all, which usually means a wrong id or the wrong tenant. enum: - resolved - not_in_flight - not_found examples: - resolved type: string state: description: >- The row's state as OBSERVED: your finding on a resolved one, the pre-existing resolution on an already-reconciled one. Absent for not_found, and absent when a concurrent resolution won — nothing read what replaced IN_FLIGHT, so nothing is claimed. examples: - ABANDONED type: string required: - operationId - aslcType - result 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 Upstream: additionalProperties: false properties: code: description: The upstream provider's own error code, verbatim. examples: - E4001 type: string message: description: >- The upstream provider's own error message, verbatim (bounded, never its raw response body). examples: - account not found at provider type: string type: object securitySchemes: BearerAuth: bearerFormat: JWT description: JWT bearer token issued by the identity provider. scheme: bearer type: http ````