List the calling client's scheduled payments (ALPHA)
Alpha — early access.
Returns the calling client’s scheduled payments (the ScheduledPayment primitive — all statuses, not just future ones), newest due first. Each shows its funding wallet (the customer’s choice at acceptance); once executed, a row also carries the covering mandate and money-path transaction as audit. Narrow the collection with the optional customer_id, signer_id, wallet_id, mandate_id, and status filters; omit them all for the full client collection. The mandate_id filter naturally matches executed rows only (a row carries no mandate until it fires).
Payments are returned in data, with meta carrying the total match count (across all pages, honouring the same filters) and whether more rows exist before or after this one. Unpaginated, meta.total_count equals the length of data and both flags are false.
Authorizations
Query Parameters
Only payments for this customer (the signer's owning agent's customer).
Only payments bound to this signer.
Only payments funded from this wallet.
Only payments that executed under this mandate (mandate_id is stamped at fire time, so this matches executed rows only).
Only payments that executed under this VERSION of the mandate — "which payments were judged against v2's caps". Use together with mandate_id; like it, this matches executed rows only.
Comma-separated statuses to include, e.g. "scheduled,executed". Allowed values: scheduled, cancelled, executed, failed. Omit for all.
Page size. OMIT FOR EVERY MATCHING PAYMENT, which is what this endpoint has always returned and remains the default — a client that does not ask to paginate must not be silently truncated. When you do page, meta.total_count and meta.has_more_after tell you where you are in the collection, so a full page is never mistaken for the end.
1 <= x <= 1001-based page number, used only alongside limit; on its own it has nothing to page through and is ignored. A page past the end is an empty list, not an error.
Rows are ordered by due date DESCENDING and then by id descending — newest due first, so page 1 carries the most recent and upcoming activity rather than the oldest settled history. The id tiebreak makes that order total, so a payment cannot be skipped or repeated across pages by sharing a due date with another.
x >= 1
