What the automation spent over time, agent by agent and part by part.
The `ledger/spend` figure bucketed by day or week: the same runs, attributed to the same agents and parts and priced the same way, so the buckets of one budget window add up to that window's `ledger/spend`. Tokens are priced per UTC day, so `HOUR` is refused. Counted live from run records, so a window reaching further back than the workspace keeps run history is counted from `countedFromMs`. Buckets with no spend are omitted. A run that spans midnight UTC puts its tool cost and credits on the day it started and the tokens it used after midnight on the next day.
Authorization
Bearer JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.
In: header
Path Parameters
The trigger identifier.
uuidThe tenant identifier
Query Parameters
Bucket granularity: DAY (default) or WEEK.
"DAY""UNSPECIFIED" | "HOUR" | "DAY" | "WEEK"Window start as Unix milliseconds (inclusive). Defaults to 30 days before to.
int64Window end as Unix milliseconds (exclusive). Defaults to now.
int64Response Body
curl -X GET "https://api.fruxon.com/v1/tenants/string/triggers/497f6eca-6276-4993-bfeb-53cbbbba6f08/ledger/spendTimeseries"{
"triggerId": "00000000-0000-0000-0000-000000000000",
"interval": "HOUR",
"window": {
"fromMs": 0,
"toMs": 0
},
"countedFromMs": 0,
"cost": 0,
"credits": 0,
"runs": 0,
"series": [
{
"agentId": "string",
"part": "ITEM_RUNS",
"cost": 0,
"credits": 0,
"runs": 0,
"points": []
}
]
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}What the automation spent in the current budget window, agent by agent.
Every agent the automation spends through, not only the ones its stages run per item: a question held as a conversation spends through the agent that holds it — its opening turn, every reply, the notices it posts and the outcome it tells — and none of those runs is named by a transition, so the funnel and the item costs cannot see them. Each agent's spend is split into what it was for. The window is the agents' own budget window (UTC, calendar-aligned), so a row here and that agent's limit are measured over the same span. An agent that also works elsewhere — chat, another automation — spends more against its limit than it spent here; that difference is the reason to read the two together. Production runs only; refused runs cost nothing and are not counted.
Partial update
Applies a partial update: only the non-null fields of the request are written. `Kind` is immutable. Agent bindings are managed through the nested `bindings` sub-resource, not this endpoint.