How this payout got to where it is
Every transition in order, with timestamps and who caused each — E6-10. Ordered by when the event was written rather than by status, because a lifecycle read back in the order the code happens to define is not a record of what occurred.
Every transition in order, with timestamps and who caused each — E6-10.
Ordered by when the event was written rather than by status, because a lifecycle read back in the order the code happens to define is not a record of what occurred.
Path Parameters
uuidResponse Body
application/json
application/json
curl -X GET "https://example.com/api/b/v1/payouts/497f6eca-6276-4993-bfeb-53cbbbba6f08/timeline"{ "payout_id": "89e4daf5-d103-4869-b9da-3d54ecc98dfe", "status": "created", "entries": [ { "event_type": "string", "at": "2019-08-24T14:15:22Z", "actor_kind": "string", "actor_id": "04f37679-bfbf-4906-b749-01756515cecf", "detail": {} } ]}Send a payout POST
Raise a payout and commit the money to it. The money is reserved before this returns, whether or not the payout needs approval. A `requires_approval` response therefore means "the funds are held and somebody must sign", not "nothing has happened yet". In **test mode** the payout is settled as it is raised: no rail is involved, so the response already carries the outcome. `amount_minor` and the destination decide what that outcome is — see the sandbox guide for the values that produce a decline, a timeout, a return or a review hold.
The limits this business is subject to GET
Being refused by a limit nobody will show you is not a control, it is an outage. Setting them is not a business action — they are ours. Pass `currency` to get the whole picture: the tier's own ceiling is derived per currency rather than stored, so without one this can only return the rows an operator has written, and a business would be held to a limit this endpoint never mentioned.