Take in client-supplied funds-recovery ids
Accepts an inventory of BACEN funds-recovery ids the client already holds and runs each one through the canonical snapshot pipeline: authoritative GET at BACEN, then apply through the same compare-and-set seam every other path uses. This is the only way a recovery older than BACEN’s seven-day event-notification window — or one whose notification was lost — becomes visible here; the window is not an inventory. Idempotent by construction: an id already at BACEN’s current version is a no-op that emits no second event, so the same batch may be re-sent safely. Each id is answered independently; a batch is capped at 50 ids per request.
Autorizaciones
JWT bearer token issued by the identity provider.
Cuerpo
BACEN-assigned funds-recovery UUIDs the client holds from its own records. Each one is fetched from BACEN and applied through the canonical snapshot pipeline. Any age and any status is accepted — this is precisely the inventory the seven-day event-notification window cannot reveal.
1 - 50 elementsSet to true to declare that the recoveries this deployment is missing — those lost to a blocked convergence gap, and those on the feed's stepped-over replay list — have now been supplied. It clears the block and empties the replay list in full, including ids this request did not carry. Every id it erases is written to the audit log by name first, along with the size of the whole inventory, so a recovery nobody ever supplied stays nameable after the list is gone. It is an assertion by the caller, recorded under the caller's identity: nothing verifies it, and nothing else lifts the block.

