List dunning runs
const url = 'http://localhost:8080/v1/dunning/runs?state=active&limit=50&offset=0';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url 'http://localhost:8080/v1/dunning/runs?state=active&limit=50&offset=0' \ --header 'Authorization: Bearer <token>'Dunning is the process of retrying a failed invoice payment on a schedule. A dunning run tracks those retries for one invoice. Runs are listed newest first.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Query Parameters
Section titled “Query Parameters”Rows per page, from 1 to 100. Default 50. Any other value, or one
that is not a whole number, is a 422 with param: limit.
Rows to skip, 0 or more. Default 0. A negative value, or one that is
not a whole number, is a 422 with param: offset.
Responses
Section titled “Responses”Dunning run list.
object
object
active: retries are running. escalated: retries ran out
(resolution is retries_exhausted). resolved: the run ended
another way; see resolution.
How the run ended, set when it is resolved. Exception:
action_failed is set on a run that is still active. The
final action (pause, cancel or mark uncollectible) failed and
will be retried at next_action_at. amount_below_minimum: a
charge on the invoice was refused by Stripe because the amount is
below its minimum charge, so the run ended without its final
action.
Filled in on list responses.
Filled in on list responses.
Filled in on list responses.
The test clock’s current time, when the customer is on a test clock. Filled in on list responses.
Filled in on list responses.
How many retries the run’s policy makes: the length of its
retry_days. Filled in on list responses.
When attempt_count has reached it, no charge is retried:
next_action_at is when the final action (pause, cancel or
mark uncollectible) runs.
How many rows match the request’s filters, on every page, not only this one. The audit log and the customer list’s search and name or email sort say where they stop counting.
Example
{ "data": [ { "state": "active", "resolution": "payment_recovered" } ]}limit or offset is out of range or not a whole number, or the request sends the removed after cursor (param names it)
object
object
One of invalid_request_error, authentication_error,
rate_limit_error or api_error. Every error the API
answers has this shape, including an unknown path (404,
code route_not_found) and a method the path does not take
(405, code method_not_allowed, with an Allow header).
The few exceptions are listed in docs/api-surface.md.
The request field the error is about. Sent only when the error
names one. A request body may hold only the fields its
operation lists, spelled and cased as listed: any other
field, or one the server sets (such as id), is refused
with 422 and param naming it. An operation with no request body lists no fields: send
no body, {} or null. The Stripe and Postmark webhooks and
the LiteLLM callback take their sender’s body as it comes.
Example
{ "error": { "type": "invalid_request_error" }}