Skavio Processing API: plan for 100 queued jobs, four active jobs and seven-day retention

Use Skavio’s queue for processing, not as your system of record. Keep excess work in a durable application backlog, treat concurrency limits as ceilings rather than reserved capacity, and save required results to your own storage promptly.

Keep the backlog outside the processing queue

Skavio Processing API sets a limit of 100 queued jobs per company and a ceiling of four active jobs per company. The deployment-wide active-job ceiling is also four. That distinction matters: four is not a promise of four dedicated slots, continuous availability or a particular completion time. Separate incoming business work from API submissions. First record each task in a durable queue or database under your control; then let a bounded dispatcher submit work as capacity permits. This follows Microsoft’s queue-based load-leveling guidance: buffering separates intake from processing, but sustained arrivals above processing capacity still grow the backlog. Do not add the two job limits together and assume that 104 unfinished jobs will always be accepted. Queue-count semantics and effective scheduling need confirmation. A queue slot is not a file allowance either: files, storage and request volume have separate limits.

Submit deliberately—and make retries repeatable

Before sending a task, persist its business reference, processing options, submission payload and idempotency key. After acceptance, associate the returned job identifier with that record. Your application should be able to restart without losing the distinction between work awaiting submission and work already accepted by Skavio. If submission times out, the outcome is uncertain: the server may have accepted the request even though the client did not receive the response. Use Skavio’s idempotent submission capability and the documented retry contract rather than creating a new logical job with a fresh key. A timeout while monitoring an existing job is different—continue tracking that job instead of submitting its source again. For transient failures, use bounded retries with capped exponential backoff and jitter. AWS’s retry guidance explains why immediate, repeated retries can amplify overload. If an HTTP 429 response includes Retry-After, respect it. The HTTP standard permits that header but does not require it, so do not assume Skavio always supplies one. Keep credit state separate from scheduling state. Submission reserves the measured quote, success charges once, and permanent failure releases the reservation. Skavio’s web processing tools and API share one Pricing V2 wallet. Available credits are another admission constraint—not evidence that processing capacity is available.

Budget monitoring, not just submissions

A batch can exhaust the request budget through status checks alone. As an illustrative calculation, polling 100 jobs individually every five seconds creates 1,200 requests per minute—ten times the supplied 120-request limit, before any other API activity. Use signed completion webhooks to trigger result retrieval, and validate their signatures according to the documentation. Keep a slower reconciliation process to check jobs whose completion notification has not been recorded. If polling is necessary, stagger requests and adjust their frequency rather than checking every queued job on the same short interval. Plan requests through one coordinated budget across your integration until the limit’s enforcement scope is confirmed. Separate workers should not each assume they have the full allowance, and additional API keys should not be treated as a way to multiply capacity. Track both API job state and your own operational state. The documented processing lifecycle is queued, processing, then completed or failed. In your application, separately record whether required outputs have actually been saved. A completed job and an archived result are not the same event.

Make result storage part of completion

Plan around the supplied seven-day result-retention period, but retrieve completed outputs promptly rather than scheduling downloads for day seven. Skavio supports authenticated result downloads; preserve any outputs needed for later review, reporting or downstream processing in storage you control. The supplied record does not establish exactly when the retention clock starts. Public documentation also describes configurable retention with a seven-day default. Confirm the applicable policy and clock start with Skavio before defining deadlines, and do not assume extensions are available. Neither result retention nor the 2 GB source-storage allowance replaces your own archive. For example, an invoice-processing workflow should keep the association between its business reference, Skavio job identifier and saved outputs. If a download fails, retry retrieval within the applicable retention window rather than automatically repeating extraction. Before production, test interrupted submissions, missed completion notifications, failed downloads and application restarts. The operational goal is straightforward: absorb bursts locally, submit at a controlled rate, and keep the download backlog small. Watch the age of your oldest unsubmitted task and your oldest completed-but-unsaved result—not just how many jobs are active.

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