Billing & Spend Caps
API runs bill identically to product UI runs. Keys optionally enforce spend caps before a run starts.
Developers responsible for API spend.
API runs bill identically to product UI runs. Keys optionally enforce spend caps before a run starts: useful for staging keys, partner integrations, and blast-radius control.
For wallet funding details, see API Runs (billing guide).
Funding order#
When a run triggers, the platform resolves funding in a fixed order. Your integration does not choose the path: but understanding it explains why some runs succeed without wallet balance.
- Eligible locked bundle for the pinned workflow version.
- Wallet balance for the displayed run price.
Spend caps#
Caps reserve estimated microdollars atomically before wallet hold. Windows: daily, monthly, or lifetime. When exceeded, POST /runs returns 402 spend_cap_reached synchronously: no run id is issued.
Pricing visibility#
Workflow list and detail responses include displayedRunPriceUsd: the estimated buyer-facing price already containing the creator margin and applicable hosted compute. Settlement charges the live displayed quote frozen at run start (same estimator as the product UI), which can differ slightly from a stale catalog snapshot. Prefer GET /workflows/{id} when you need the freshest estimate; pricingExplanation states when the field is an estimate. Non-hosted credential modes use Edgaze's orchestration pricing while the provider bills the credential owner. GET /runs/{id} returns displayedChargeUsd after settlement. Raw compute cost is never exposed via the API.
Was this useful?
Your response helps us improve the documentation.