> ## 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. # Liberar las operaciones retenidas tras agotar su presupuesto de intentos salientes > Libera la reserva de transmisión saliente de las operaciones indicadas y las devuelve al backlog elegible para que el siguiente tick de drenaje vuelva a procesarlas. RBAC: connectivity:admin. Es la ÚNICA ruta de recuperación para una operación PARKED. AMBAS etapas salientes aparcan por el MISMO motivo, informado en parkReason como attempt_budget_exhausted: N rechazos consecutivos de la contraparte agotaron el presupuesto de intentos de la operación (SCHEDULE_DISPATCH_MAX_TRANSMIT_ATTEMPTS, valor predeterminado 20). Lo que cambia es la etapa y el estado restante, que la alerta informa en stage: un archivo FORWARD (ASLC022/024/032/061/065 hacia la IF Domicilio) deja la operación ACCEPTED, reprocesada por el tick de forward; un archivo DISPATCH (ASLC027/029/031/060/064 hacia Núclea) la deja QUEUED, reprocesada por el tick de dispatch. El valor permanent_rejection está RETIRADO y ya no se emite — ninguna respuesta 4xx por sí sola aporta evidencia para aparcar un archivo —, pero las alertas históricas aún lo contienen. En ambos casos, la reserva retenida vuelve la operación invisible para todos los drenajes, y cualquier otro verbo administrativo es un callejón sin salida: /advance rechaza la transición sin efecto hacia el mismo estado, /requeue solo admite CREATED, /retry solo admite REJECTED y /retransmit rechaza el estado (una operación forward aparcada está ACCEPTED, no QUEUED) o pierde su propia CAS de reserva y responde 409 in-flight (una operación dispatch aparcada ESTÁ QUEUED). Enumera los ids con GET /v1/operations?transmitHold=parked, la lista canónica, paginada y limitada al tenant; la alerta operation.forward_rejected (payload operationIds) y el campo parked_operation_ids del log ERROR del aparcado son extractos de primera respuesta del mismo conjunto, y el webhook diario solo nombra el primer archivo aparcado ese día. No existe una forma para todo el scope: una reserva de transmisión retenida es AMBIGUA entre una operación aparcada y otra cuyo archivo ya está en Núclea, y solo quien llama decide qué conjunto liberar. Este verbo RECHAZA el segundo tipo con 409 cuando está marcado como tal (transmitHold=in_flight): reconcilia esas operaciones con Núclea y procesa cada una mediante POST /v1/operations/{operationId}/advance; nunca las desaparques. Idempotente: repetir la llamada no libera nada más e informa released=0. Se omiten las reservas con menos del margen de seguridad de 5 minutos, pues pueden pertenecer a una ejecución en pleno envío. La liberación también reinicia el presupuesto de intentos, por lo que una operación recuperada recibe el presupuesto completo en lugar de volver a aparcarse en el siguiente rechazo. Se ejecuta sin locks y no transmite nada. ## OpenAPI ````yaml es/openapi/v3-current/slc.yaml post /v1/connectivity/unpark openapi: 3.1.0 info: description: >- API de Lerian SLC — el rail del lado del participante que conecta la institución con la liquidación de tarjetas por neto diferido SLC de Núclea. Cubre la admisión y el ciclo de vida de las operaciones de liquidación, las posiciones de compensación, el registro de participantes y arreglos, los informes generados, la consulta de esquemas XSD integrados, la recuperación de transmisión y la conectividad con Núclea, la importación de clave de firma BYOK Modelo A y los webhooks con alcance al tenant. title: Lerian SLC API version: 1.0.0 servers: - url: https://slc.sandbox.lerian.net security: - BearerAuth: [] tags: - description: >- Ciclo de vida de las operaciones de liquidación — crea, lista, consulta y controla las operaciones de tarjeta rastreadas por NUliquid (NUliquid = el id de 21 posiciones que Núclea asigna a cada operación aceptada) a través de la máquina de estados. name: Operations - description: >- Catálogo de participantes — los adquirentes, subadquirentes, IF Domicílio (banco donde el establecimiento recibe sus ventas) y las IF de liquidación (instituciones financieras) que participan en la liquidación de tarjetas. name: Participants - description: >- Arreglos de tarjeta (configuraciones de bandeira/esquema, p. ej. Visa/Master/Elo) asociados a un participante. name: Arrangements - description: >- Orquestación de transporte regulado hacia Núclea/SILOC (la cámara de compensación privada de tarjetas que opera el sistema de liquidación SILOC) — despacho, recuperación, retransmisión y prueba de conectividad sobre transferencia de archivos gestionada, broker de mensajes y REST. name: Connectivity - description: >- Posiciones de compensación de neteo multilateral — el monto neto que cada participante liquida por ciclo STR (STR = sistema de transferencia de reservas del Banco Central). name: Clearing - description: >- Aprovisionamiento de clave de firma SaaS BYOK (Bring Your Own Key) — importa parámetros y registra el material del certificado ICP-Brasil A1 del cliente (certificado de servidor de la PKI brasileña, validez de 1 año) usado para firmar archivos ASLC; la clave privada nunca sale del HSM/KMS/Vault del cliente. name: SigningKey - description: >- Admisión y estado de archivos ASLC — envío en modo passthrough y estado de procesamiento de los archivos XML oficiales de liquidación de tarjetas de Núclea (ASLC = Arquivo do Sistema de Liquidação de Cartões). name: Files - description: >- Introspección de solo lectura de los esquemas XSD ASLC/RSFN (Red del Sistema Financiero Nacional) integrados de Núclea usados para validar los mensajes salientes y entrantes. name: XSD Schemas - description: >- Informes de liquidación regulatorios, de cumplimiento y operativos, de solo lectura. name: Reports - description: >- Suscripciones a webhooks de eventos de negocio salientes y gestión de entrega para los consumidores (Midaz, ledgers del cliente, Cabine — todos opcionales). name: Webhooks - description: >- Operaciones administrativas — configuración de tiempo de ejecución recargable en caliente, inspección/reenvío de la cola de mensajes muertos y redespacho del outbox. name: Admin paths: /v1/connectivity/unpark: post: tags: - Connectivity summary: >- Liberar las operaciones retenidas tras agotar su presupuesto de intentos salientes description: >- Libera la reserva de transmisión saliente de las operaciones indicadas y las devuelve al backlog elegible para que el siguiente tick de drenaje vuelva a procesarlas. RBAC: connectivity:admin. Es la ÚNICA ruta de recuperación para una operación PARKED. AMBAS etapas salientes aparcan por el MISMO motivo, informado en parkReason como attempt_budget_exhausted: N rechazos consecutivos de la contraparte agotaron el presupuesto de intentos de la operación (SCHEDULE_DISPATCH_MAX_TRANSMIT_ATTEMPTS, valor predeterminado 20). Lo que cambia es la etapa y el estado restante, que la alerta informa en stage: un archivo FORWARD (ASLC022/024/032/061/065 hacia la IF Domicilio) deja la operación ACCEPTED, reprocesada por el tick de forward; un archivo DISPATCH (ASLC027/029/031/060/064 hacia Núclea) la deja QUEUED, reprocesada por el tick de dispatch. El valor permanent_rejection está RETIRADO y ya no se emite — ninguna respuesta 4xx por sí sola aporta evidencia para aparcar un archivo —, pero las alertas históricas aún lo contienen. En ambos casos, la reserva retenida vuelve la operación invisible para todos los drenajes, y cualquier otro verbo administrativo es un callejón sin salida: /advance rechaza la transición sin efecto hacia el mismo estado, /requeue solo admite CREATED, /retry solo admite REJECTED y /retransmit rechaza el estado (una operación forward aparcada está ACCEPTED, no QUEUED) o pierde su propia CAS de reserva y responde 409 in-flight (una operación dispatch aparcada ESTÁ QUEUED). Enumera los ids con GET /v1/operations?transmitHold=parked, la lista canónica, paginada y limitada al tenant; la alerta operation.forward_rejected (payload operationIds) y el campo parked_operation_ids del log ERROR del aparcado son extractos de primera respuesta del mismo conjunto, y el webhook diario solo nombra el primer archivo aparcado ese día. No existe una forma para todo el scope: una reserva de transmisión retenida es AMBIGUA entre una operación aparcada y otra cuyo archivo ya está en Núclea, y solo quien llama decide qué conjunto liberar. Este verbo RECHAZA el segundo tipo con 409 cuando está marcado como tal (transmitHold=in_flight): reconcilia esas operaciones con Núclea y procesa cada una mediante POST /v1/operations/{operationId}/advance; nunca las desaparques. Idempotente: repetir la llamada no libera nada más e informa released=0. Se omiten las reservas con menos del margen de seguridad de 5 minutos, pues pueden pertenecer a una ejecución en pleno envío. La liberación también reinicia el presupuesto de intentos, por lo que una operación recuperada recibe el presupuesto completo en lugar de volver a aparcarse en el siguiente rechazo. Se ejecuta sin locks y no transmite nada. 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 ````