Docs Objects
Recurrence
LiveUpdated
Agents. Written for people who build agents, the hosts they run in, and the people and companies the agents pay for.
A recurrence is a standing authorization to pay one payee on a schedule: at most so much each time, at most so much in total, until an end date. It never pays by itself. When an occurrence is due, Enruta creates a payment request under the recurrence, decides it against the policy like any other request, and seals the payment as a record chained to the recurrence.
Create one
POST /v0/recurrences Authorization: Bearer enruta_dev_…
{
"agent_id": "agt_procurement_02",
"payee": { "name": "Ream & Rule", "domain": "reamandrule.com" },
"currency": "USD",
"per_occurrence_max": "120.00",
"cumulative_max": "1200.00",
"amount_variance": { "type": "variable", "pct": 10 },
"schedule": { "interval": "monthly", "anchor": "2026-10-01" },
"end_date": "2027-09-30",
"consent_id": "cns_01M2F0Q3W7T1K5N9B4D8H2XR",
"purpose": "Monthly office supplies restock"
}Fields
| Field | Meaning |
|---|---|
id | rcu_… |
agent_id | The agent the payments are made by |
payee | { name, domain }: the one payee every occurrence pays |
currency, per_occurrence_max, cumulative_max | Two caps, as decimal strings |
amount_variance | { type: "fixed" }, the same amount every time, or { type: "variable", pct }, an amount that may move by up to pct percent |
schedule | { interval: "weekly" | "monthly", anchor }: how often, counted from the anchor date |
end_date | Optional; no occurrence after it |
consent_id | Optional: the consent record that authorizes the series |
purpose | What the payments are for, in words |
status | Active, paused or ended |
occurrences_count, cumulative_amount, next_run_at | Where the series stands |
first_network_transaction_id | The network transaction id of the first customer-initiated payment, kept when the rail reports it, for the payments that follow |
recurrence_record_id | The sealed linked record |
How an occurrence is decided
- When an occurrence is due, the recurrence job creates a payment request with
chain: { relation: "occurrence_of" }pointing at the recurrence record. - The request goes through the whole decision: the policy, the consent, the intent, the agent’s identity, the merchant check, the budget. A denial or a step-up is sealed like any other.
- An occurrence above
per_occurrence_maxsteps up: a person approves that occurrence. - An occurrence that would take the series past
cumulative_maxis denied. - The payment record carries
chain.relation: occurrence_ofand the recurrence record; the recurrence record carrieschain.relation: recurrence_forand its consent, when there is one.
Change it
PATCH /v0/recurrences/{id} pauses, resumes or ends a series. Creation and every change seal a kind: recurrence linked record, so the history of the series verifies like its payments. GET /v0/recurrences/{id}/occurrences lists the payments made under it.
Example
Halvern’s procurement agent restocks office supplies once a month, at most $120 a time and $1,200 in all. In March the order comes to $131.40, above per_occurrence_max, so that occurrence steps up and the person who approves signs it; its record is occurrence_of the recurrence. By September the series has spent $1,150, so a $90 occurrence would pass cumulative_max and is denied, and the denial is sealed too.
Interfaces
| Surface | Call |
|---|---|
| REST | POST /v0/recurrences, GET /v0/recurrences, GET /v0/recurrences/{id}, PATCH /v0/recurrences/{id}, GET /v0/recurrences/{id}/occurrences |
| MCP | list_recurrences (read-only) |
| Webhooks | recurrence.created, recurrence.paused, recurrence.resumed, recurrence.ended (also when the schedule reaches end_date), recurrence.occurrence_created |
| SDK | recurrences.* |
| CLI | enruta recurrence ls, enruta recurrence create, enruta recurrence pause | resume | end <rcu_id> |
| Console | /recurrences |