Retry accrual run items
Re-sends to the ledger the recognitions of a run that it has not acknowledged. Of the items selected, only those still unposted are re-sent; an acknowledged recognition is never sent twice, and each re-send carries the same deterministic key as the original attempt, so a recognition already in the ledger is deduplicated there rather than booked again. The response lists the items actually re-sent, which may be fewer than those asked for; whatever it could not send is listed in unpostableItems with a reason. Status is “queued” when at least one recognition went out, “nothing_to_retry” only when the ledger had already acknowledged everything selected, and “blocked” when unacknowledged recognitions exist and none of them could be re-sent. An id that belongs to no item of this run is refused with 422 (LENDER-0407) before any of that is decided, and nothing is re-sent — so “nothing_to_retry” can only ever mean the ledger has everything selected. That refusal names AT MOST TEN unknown ids, one per errors[] member at body.itemIds; the detail always states how many there are in total, so a selection with more than ten unknown ids reports the true count and lists the first ten. Safe to repeat: pressing retry twice enqueues one posting per recognition.
Encabezados
Cuerpo
Accrual run item identifiers to retry. Selecting an item the ledger has already acknowledged is not an error — it is skipped, and the response says which items were actually re-sent. An id that is not an item of this run IS an error: the whole request is refused with 422 and the unknown ids are named.
1 - 500 elementsRespuesta
OK
"queued" when at least one recognition was re-sent and is waiting for the ledger; "nothing_to_retry" when the ledger had already acknowledged every selected recognition, which is a success and not an error; "blocked" when recognitions the ledger has NOT acknowledged exist and none of them could be re-sent — money is still outside the ledger and unpostableItems says why.
"queued"

