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.