> ## Documentation Index
> Fetch the complete documentation index at: https://apidocs.overtenai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Credits and billing

> How Overten prices API usage and how credits are deducted.

Every successful generation consumes credits from your organization's
balance. This page documents the exact behavior that ships today —
pricing specifics are set per-tier and per-deal; contact
[sales](mailto:sales@overten.ai) for a rate card.

## What costs credits

Today, only **successful generation runs** cost credits:

* `POST /excel/generate`, `/word/generate`, `/slides/generate`
* `POST /excel/analyze`
* `POST /text/humanize`, `/text/rewrite`, `/text/new-content`

Everything else — `GET /runs`, `/tasks`, `/verify`, `/webhooks`,
`POST /files` (upload), `DELETE /images/{id}`, edit-URL rendering,
preflight — is free. File storage and bandwidth are not billed
separately in v1.

## How a run is priced

The `credits_used` returned on every completed response is the
**authoritative** charge for that run. It's derived from the real
model-token usage for all LLM turns inside the run plus the agent's
tool activity.

We don't publish a static per-format rate card in v1. Prices depend on:

* The models used during the run (varies by request shape and tier).
* How much the agent had to iterate — a short prompt on a small sheet
  costs a fraction of a multi-sheet model that took 20 agent turns.
* Whether preflight rejected the call (rejection is free; see
  [Preflight](/concepts/preflight)).

If you need budgeting numbers for procurement or capacity planning,
reach out — we'll share the pricing worksheet for your tier.

## Balance check before a run

Before a generation request is accepted, we verify your balance is
above a small safety floor. If it isn't, the API returns:

```json theme={null}
402 Insufficient credits
{
  "success": false,
  "error": "insufficient_credits",
  "message": "Insufficient credits. Required: N, balance: M."
}
```

The `Required` value is the minimum we need on file before starting.
It's deliberately conservative so we never start work you can't afford
to complete. The actual deduction after success is usually smaller or
similar — it's the *real* usage, not the pre-flight estimate.

This check runs **before** the preflight LLM and the document pipeline,
so you never pay for a run that was rejected for insufficient balance.

## When you're charged

| Event                                                   | Credits charged?                 |
| ------------------------------------------------------- | -------------------------------- |
| Request rejected by balance check (402)                 | No                               |
| Request rejected by preflight (`preflight_failed`)      | No                               |
| Request rejected by permissions / auth                  | No                               |
| Agent runs, **succeeds**                                | Yes — `credits_used` on response |
| Agent runs, **fails** mid-execution                     | No (v1 behavior)                 |
| Sync auto-promoted to async then succeeds on the worker | Yes                              |
| Async worker job fails                                  | No                               |

v1 behavior for failures: if a run crashes after starting, we don't
charge. This is deliberately customer-friendly; if it ever changes
we'll update this page and the changelog before enforcing.

## Top-ups and balance visibility

Top-ups are applied immediately — the next request sees the new
balance. Your balance is visible at
[app.overten.ai](https://app.overten.ai) → **Settings → Billing**, or
by contacting support with your `org_id`.

Individual run costs are returned on the `credits_used` field of every
completed response, so you can reconcile spend from your own logs.

## Refunds

If a completed run produced something unusable — wrong format,
corrupted output, an edge case that slipped through preflight — open a
support ticket with the `run_id`. We'll pull the internal ledger row,
verify what happened, and issue a credit on a case-by-case basis.

We don't refund "I didn't like the result" — the agent produced the
artifact you asked for, even if the prompt was underspecified. Better
prompting, not post-hoc refunds, is the fix there. Work with support
on patterns that misbehave and we'll tune the agents.

## Audit trail

Every credit movement — deduction, top-up, refund — is written to an
internal ledger keyed by `(org_id, run_id, timestamp, delta)`. For
billing disputes, reference the `run_id` from your response payload
and support can pull the matching row.

Individual run responses and `GET /runs/{run_id}` both expose
`credits_used`, so you can reconcile your local records without
needing dashboard access.

## Observability

Per-run cost attribution — which turn, which tool, which model —
is visible to our team via our observability backend. If you're
debugging why a specific run cost what it did, file a support ticket
with the `run_id` and we can walk you through the breakdown.

Customer-side observability export (your own Langfuse / Datadog
destination) is available on enterprise tier. Contact sales for setup.