Pricing

Every task is paid in credits of one credit type (credit_type). Prices can change, so read them live.

• What every task costs, per option: GET /v1/pricing (any valid key; no scope needed). GET /v1/pricing?task=image.generate answers one task.
• What YOUR request costs: POST /v1/tasks/{name}/estimate with the body you would submit. It holds nothing, and answers the most that request can cost (ceiling).

What sets a price

A task's price is adjusted by the options you choose:

• Options. Some option values change the price (for example a higher resolution). Each GET /v1/pricing entry lists the options that do in prices[] ({options, credits, credit_type}), and the ones that do not in unchanged.
• Counts. A task that makes several outputs (image_count) is priced per output: the entry's per names the count, and each prices[] row is the price of one.
• List lengths. A task priced by how many items you send (images of a moodboard) lists the price at each length in sizes.
• The input. Which image or record you send does not change a price, with three exceptions the entry states in rule (and prices its example request): a shoot is priced per photo it plans (products × looks × models × views), an edit can cost differently depending on where the image you send was made, and a task that reads a record (a fabric's colours, a range plan's looks) is priced by what the record holds. For these, /estimate is the price of your request.
• Tasks without a charge answer credits: 0 and no credit type: credit_type is null (in /v1/pricing, /estimate and /v1/account/usage alike).

Credits

A task is paid in one credit type (credit_type — it is in every GET /v1/pricing row and in every /estimate answer). The values and what each is spent on: GET /v1/vocab/credit_type.

Your balance, one entry per credit type: GET /v1/account/balance. Each entry's remaining is what you can spend now (a job asking for more is refused), and expiring lists when your credits run out, one entry per batch in the order they are spent:

{ "balances": [
    { "credit_type": "<credit type>", "remaining": <credits>,
      "expiring": [ { "credits": <credits>, "at": "2026-10-31T23:59:59Z" } ] } ],
  "as_of": "2026-10-05T12:00:00Z" }

Every credit type (GET /v1/vocab/credit_type) is listed, with remaining 0 when you have none. On a team, remaining also respects your own share of the team's credits, so the expiring entries need not add up to it.

• A plan's credits renew each billing period and are used within it.
• A credit pack's credits end on the pack's own date.
• Credits are spent in this order: your own credits before your team's, a plan's credits before a pack's, and among those the ones that run out soonest first.

What is charged

• Submitting a job holds the estimate (a ceiling): the response's X-Refabric-Credits header is the amount held and X-Refabric-Credit-Type its credit type (Jobs).
• Only what is delivered is charged; the rest of the hold comes back when the job ends, whether it succeeded, failed or was cancelled.
• What you spent, per task and per key: GET /v1/account/usage (Usage).
• A price change shows in GET /v1/pricing and /estimate at once. A changed price is listed in the changelog.