> ## 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. # Un-park operations held after exhausting their outbound attempt budget > Clears the outbound transmit claim of the named operations, returning them to the eligible backlog so the next drain tick re-drives them. RBAC: connectivity:admin. It is the ONLY recovery path for a PARKED operation. BOTH outbound stages park for the SAME reason, reported in parkReason as attempt_budget_exhausted: N consecutive counterpart refusals exhausted the operation's attempt budget (SCHEDULE_DISPATCH_MAX_TRANSMIT_ATTEMPTS, default 20). What differs is the stage and the state left behind, which the alert reports in stage: a FORWARD file (ASLC022/024/032/061/065 to the IF Domicilio) leaves the operation ACCEPTED, re-driven by the forward tick; a DISPATCH file (ASLC027/029/031/060/064 to Núclea) leaves it QUEUED, re-driven by the dispatch tick. The value permanent_rejection is RETIRED and no longer emitted - no single 4xx response carries the evidence to park a file - but historical alerts still carry it. Either way the held claim makes it invisible to every drain, and every other admin verb is a dead end: /advance rejects the no-op self-edge, /requeue is CREATED-only, /retry is REJECTED-only, and /retransmit either rejects the state (a parked forward op is ACCEPTED, not QUEUED) or loses its own claim CAS and answers 409 in-flight (a parked dispatch op IS QUEUED). Enumerate the ids with GET /v1/operations?transmitHold=parked, which is the authoritative, paginated, tenant-scoped list; the operation.forward_rejected alert (payload operationIds) and the park's ERROR log field parked_operation_ids are first-response excerpts of the same set, and the daily webhook names only the first file parked that day. There is no scope-wide form: a held transmit claim is AMBIGUOUS between a parked operation and one whose file is already at Núclea, and only the caller decides which set to release. This verb REFUSES the second kind with 409 when it is marked as such (transmitHold=in_flight) - reconcile those with Núclea and drive each one with POST /v1/operations/{operationId}/advance instead, never un-park them. Idempotent: re-running releases nothing further and reports released=0. Claims younger than the 5-minute safety floor are skipped (they may belong to a pass that is mid-submit). Un-parking also zeroes the attempt budget, so a recovered operation gets a full budget rather than re-parking on its next refusal. Runs lock-free: it transmits nothing. ## OpenAPI ````yaml en/openapi/v3-current/slc.yaml post /v1/connectivity/unpark 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/connectivity/unpark: post: tags: - Connectivity summary: Un-park operations held after exhausting their outbound attempt budget description: >- Clears the outbound transmit claim of the named operations, returning them to the eligible backlog so the next drain tick re-drives them. RBAC: connectivity:admin. It is the ONLY recovery path for a PARKED operation. BOTH outbound stages park for the SAME reason, reported in parkReason as attempt_budget_exhausted: N consecutive counterpart refusals exhausted the operation's attempt budget (SCHEDULE_DISPATCH_MAX_TRANSMIT_ATTEMPTS, default 20). What differs is the stage and the state left behind, which the alert reports in stage: a FORWARD file (ASLC022/024/032/061/065 to the IF Domicilio) leaves the operation ACCEPTED, re-driven by the forward tick; a DISPATCH file (ASLC027/029/031/060/064 to Núclea) leaves it QUEUED, re-driven by the dispatch tick. The value permanent_rejection is RETIRED and no longer emitted - no single 4xx response carries the evidence to park a file - but historical alerts still carry it. Either way the held claim makes it invisible to every drain, and every other admin verb is a dead end: /advance rejects the no-op self-edge, /requeue is CREATED-only, /retry is REJECTED-only, and /retransmit either rejects the state (a parked forward op is ACCEPTED, not QUEUED) or loses its own claim CAS and answers 409 in-flight (a parked dispatch op IS QUEUED). Enumerate the ids with GET /v1/operations?transmitHold=parked, which is the authoritative, paginated, tenant-scoped list; the operation.forward_rejected alert (payload operationIds) and the park's ERROR log field parked_operation_ids are first-response excerpts of the same set, and the daily webhook names only the first file parked that day. There is no scope-wide form: a held transmit claim is AMBIGUOUS between a parked operation and one whose file is already at Núclea, and only the caller decides which set to release. This verb REFUSES the second kind with 409 when it is marked as such (transmitHold=in_flight) - reconcile those with Núclea and drive each one with POST /v1/operations/{operationId}/advance instead, never un-park them. Idempotent: re-running releases nothing further and reports released=0. Claims younger than the 5-minute safety floor are skipped (they may belong to a pass that is mid-submit). Un-parking also zeroes the attempt budget, so a recovered operation gets a full budget rather than re-parking on its next refusal. Runs lock-free: it transmits nothing. operationId: recoveryUnpark requestBody: content: application/json: schema: $ref: '#/components/schemas/RecoveryUnparkRequest' required: true responses: '200': content: application/json: schema: $ref: '#/components/schemas/RecoveryUnparkResponse' description: OK '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: RecoveryUnparkRequest: additionalProperties: false properties: confirmedNotAtNuclea: description: >- Set ONLY after reconciling with Núclea and confirming the file was NOT accepted. Without it, an operation whose transmit hold is in_flight is refused with 409, because releasing it would re-submit an accepted settlement file. With it, those ids are released too and the decision is logged at ERROR with your reason. Núclea's synchronous 202 means "accepted for processing", not settled, so this case is real - but it is the caller's finding, never a default. examples: - false type: boolean operationIds: description: >- Parked operation ids to un-park. Enumerate them with GET /v1/operations?transmitHold=parked, which is the authoritative, paginated, tenant-scoped list; the operation.forward_rejected alert (payload operationIds) and the park's ERROR log field parked_operation_ids are first-response excerpts of the same set. 1..500 UUIDs. examples: - - 018f8a3e-4b2c-7c1a-9e5d-2f6a1b3c4d5e items: type: string type: - array - 'null' reason: description: >- How it was confirmed that Núclea did not accept the file. REQUIRED when confirmedNotAtNuclea is true; it is the audit record of who decided to release a possibly-in-flight settlement. examples: - >- Núclea support ticket 48210: file ASLC022_62313268_20260724_00006 not received; no NUliquid issued. type: string required: - operationIds type: object RecoveryUnparkResponse: additionalProperties: false properties: action: description: Recovery action that was executed. examples: - unpark type: string released: description: >- Transmit claims actually cleared; these operations are back in the eligible backlog. examples: - 2 format: int64 type: integer requested: description: Distinct operation ids named in the request. examples: - 3 format: int64 type: integer skipped: description: >- Ids that carried no transmit claim (never parked, or already un-parked) or whose claim is younger than the safety floor. examples: - 1 format: int64 type: integer required: - action - requested - released - skipped type: object Detail: additionalProperties: false properties: code: description: >- Stable, machine-readable domain error code scoped to the emitting service (format: -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 ````