Skip to main content
Both reads answer Cache-Control: no-store. The *Microusd fields are integers in micro-USD, so 1000000 is one dollar; usd and usdDisplay are strings. No money figure in this API is a float.

​
The five terminal states

status is running until the run lands, and then it is exactly one of these and never changes again. A polling loop should treat any status other than running as the end.
A terminal run is not necessarily an empty one, and done is not the only success. stopped and budget_exhausted both carry a result with the rows that passed the full funnel before the run ended, usually with result.met false. Treating anything other than done as a failure throws away rows you have already paid for.The reverse also holds: result can be null on a terminal run. An interrupted run that died before writing its tail has no final event to return, and neither does the error row left behind by a 402. Check the field rather than the status.

​
Reading a stopped or exhausted run

The final event in result carries stopped: true and stopped_at whatever the early ending was: your stop, the spend ceiling, the balance running out, the deadline, or a lost process. So result.stopped tells you the table is partial, and status tells you why it is partial. One without the other is not enough.

​
Cost on the run

billableAccruedMicrousd is on the same scale as the usd on a cost event: what you are charged, with nothing in it that the cost events do not also report. The amount actually captured when the run settles is billableAccruedMicrousd + billableInFlightMicrousd as of the moment it ended, capped at the hold, so a run that was mid-call when it stopped is charged for that call. The hold itself is not a field on the run. It is released down to the captured amount when the run settles, and the settlement lands before status becomes terminal, so a terminal run is never still holding money. See Cost.