POST /payouts call, from 1 to 100. It carries the call’s name, description, reference and metadata, aggregates its payouts’ totals, and derives a status from theirs, so you can follow a payroll run or an invoice cycle as one unit. Batches are created only through POST /payouts; there’s no separate create endpoint.
The batch object
Response (abridged)
Batch statuses
A batch’s status is derived from its payouts and recalculated whenever one of them changes, so it can move more than once and can move backwards: a batch that wasprocessing returns to awaiting_payees when the only payout left is waiting for its payee.
A returned payout counts as not delivered. A
completed batch therefore becomes partially_completed, or failed, if one of its payouts is later returned.
List batches
GET /batches filters by status, created[gte] and created[lte], returns results newest first and pages with limit and starting_after. To list a batch’s payouts with filters, use GET /payouts?batch_id=batch_fcb4cuwtd6fcbmwr.
Canceling
Batches can’t be canceled as a whole. Cancel each payout that’s still on hold withPOST /payouts/{id}/cancel; the batch’s status follows.
Events
A batch emitsbatch.created when it’s created, then an event each time its status changes: batch.processing, batch.awaiting_payees, batch.awaiting_funds, batch.completed, batch.partially_completed, batch.failed and batch.canceled. A single payout change often produces two events, such as payout.paid followed by batch.completed; they aren’t guaranteed to arrive in that order.