Docs Objects

Recurrence

LiveUpdated

View as Markdown

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

FieldMeaning
idrcu_…
agent_idThe agent the payments are made by
payee{ name, domain }: the one payee every occurrence pays
currency, per_occurrence_max, cumulative_maxTwo 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_dateOptional; no occurrence after it
consent_idOptional: the consent record that authorizes the series
purposeWhat the payments are for, in words
statusActive, paused or ended
occurrences_count, cumulative_amount, next_run_atWhere the series stands
first_network_transaction_idThe network transaction id of the first customer-initiated payment, kept when the rail reports it, for the payments that follow
recurrence_record_idThe 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_max steps up: a person approves that occurrence.
  • An occurrence that would take the series past cumulative_max is denied.
  • The payment record carries chain.relation: occurrence_of and the recurrence record; the recurrence record carries chain.relation: recurrence_for and 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

SurfaceCall
RESTPOST /v0/recurrences, GET /v0/recurrences, GET /v0/recurrences/{id}, PATCH /v0/recurrences/{id}, GET /v0/recurrences/{id}/occurrences
MCPlist_recurrences (read-only)
Webhooksrecurrence.created, recurrence.paused, recurrence.resumed, recurrence.ended (also when the schedule reaches end_date), recurrence.occurrence_created
SDKrecurrences.*
CLIenruta recurrence ls, enruta recurrence create, enruta recurrence pause | resume | end <rcu_id>
Console/recurrences