Fixed quotes, reserved credits: how Skavio settles a processing job

Skavio Processing API separates committing credits from consuming them. Submission atomically reserves a measured quote; success charges that amount once; permanent failure releases the reservation. For an integration, the useful distinction is not simply whether a job has started, but whether its credits are available, reserved or consumed.

Measure the work before committing credits

POST /v1/estimate measures source bytes, PDF pages or media duration without starting processing. That gives an application a credit estimate based on the source and requested operation, rather than a guess based on a filename or expected document length. The documented max_credits field adds a caller-defined credit cap: a job is rejected if its quote exceeds that cap. This is useful when an integration accepts files whose page count or duration is not known in advance. The fixed-quote commitment described here is the measured quote reserved at submission. Do not assume an earlier estimate locks pricing before submission.

An atomic reservation is a hold, not a charge

All Skavio web processing tools and the Processing API use one company Pricing V2 wallet. A workflow running through the API therefore draws on the same credits as processing started through the web tools. At submission, the quoted credits are reserved atomically. Atomic means the reservation takes effect as one all-or-nothing operation. Those credits are committed to the job, but they have not yet been consumed. A balance checked earlier by a client is not itself a reservation—an important distinction when several jobs share a wallet. Consider a hypothetical four-page Flow document. At 25 credits per page, its quote is 100 credits. If the company starts with 1,000 available credits and has no other activity, submission leaves 900 available and 100 reserved.

Settlement follows the outcome—not every error

The job's final outcome determines what happens to its reservation. Using the same hypothetical 100-credit job, there are two settlement paths: success or permanent failure. Temporary interruptions are different: a provider outage can leave a job queued with its reservation intact. A timeout or temporary error is therefore not evidence that the job has permanently failed or that its credits have been released. Integrations should follow the job's recorded outcome rather than infer settlement from a failed client request.

• Success: the fixed quote is charged once. The example ends with 900 available credits, zero reserved and 100 consumed by the job.
• Permanent failure: the full reservation is released. The example returns to 1,000 available credits, with zero reserved and no credits consumed by that job.
• Temporary interruption: the reservation can remain in place while the job waits. Do not assume an immediate release.

Retry the submission without creating a second job

A client can lose the response to a submission even though the server accepted it. Creating a fresh submission at that point risks requesting another job rather than recovering the first one. Skavio supports idempotent submissions: retrying an identical submission with its original Idempotency-Key returns the same job without another charge. Reusing that key with changed parameters returns HTTP 409. An intentional retry after terminal failure is a new job and needs a new key. This is a submission safeguard, not a broad promise of exactly-once external execution or webhook delivery. HTTP does not make arbitrary POST retries safe automatically; the integration must preserve the submission's idempotency key.

Keep credit accounting separate from cash payments

A reservation reduces available credits without yet recording consumption. A successful job settles the fixed quote. A permanently failed job releases the hold; that release is not a cash refund. For operational records, keep the job identifier, idempotency key, quoted credits and final outcome together. Report reserved credits separately from consumed credits so that queued work is not mistaken for completed spending. Credit consumption, cash receipts and provider or infrastructure costs are distinct records. Releasing a failed job's reservation does not establish that processing incurred no underlying cost. The value of this lifecycle is a defined credit commitment for each submitted job, with an explicit settlement path for success and permanent failure.

Read the Processing API documentation at https://www.skavio.eu/api/docs/ →