Payout lifecycle

Every payout moves through a small state machine. Each transition emits a webhook event whose payload matches the GET /payout/{id} schema.

States

Status	Meaning
`created`	The payout exists and is pending approval by the sending team. The recipient can already be invited to claim.
`approved`	The sending team approved the payout (dashboard, approval session, or `preApproved` creation). Funds are reserved against the team wallet.
`requested`	The recipient claimed the payout and chose a payout method; the transfer has been requested from the payment provider.
`completed`	The transfer settled. Terminal.
`deleted`	The payout was deleted before completion. Terminal.
`expired`	The payout expired unclaimed. Terminal.

The happy path is created → approved → requested → completed.

Approval order is not fixed: a recipient can claim before approval — the transfer waits until the payout is both approved and funded.
A provider rejection after requested does not complete the payout: it stays requested while the failure is handled (in the sandbox you can force this with the failure triggers listed in Create a payout).
availableOn delays claimability, not creation: the payout exists immediately but can only be claimed from that date.
Deleting (DELETE /payout/{id}) is only possible before the recipient requests the payout: created, approved and expired payouts can be deleted, requested and completed payouts cannot (HTTP 409).
From requested on, recipientInvoiceSource says who wrote the document behind recipientInvoice: self-billing (Talentir issued it in the recipient's name) or recipient-upload (the recipient uploaded their own invoice while claiming).