Skavio Processing API: plan around 2 GB of source storage and seven-day retention
Skavio Processing API specifies a 2 GB company source-storage allowance and seven-day retention. These are separate integration constraints: available capacity determines how much source data you can hold, while retention makes prompt preservation of required outputs essential. Treat processing storage as a temporary workspace—not your business archive.
1. Check batch limits and company capacity separately
The 2 GB source-storage allowance is company-scoped, not an allowance per file, job or API key. Multiple uploaders therefore need a shared capacity plan; separate keys do not create separate storage budgets. Upload limits are a different constraint: a batch may contain up to 100 files and 500 MB total. Staying within those limits does not establish that sufficient company storage remains. Before implementing exact byte-level quota checks, confirm the applicable units and which objects count. Public documentation also describes a default 2 GiB shared source/result quota, which differs from the 2 GB company source-storage allowance used here. Do not treat those descriptions as interchangeable or assume whether outputs consume the allowance.
- Check each batch against both the file-count and total-size upload limits.
- Coordinate intake across uploaders serving the same company.
- Leave capacity headroom rather than planning to fill the allowance exactly.
2. Keep your source of record outside the processing lifecycle
Retain originals in storage you control when your workflow needs them for review, audit or reprocessing. Apply your own access controls and retention policy rather than relying on the API’s temporary storage. Seven-day retention is a reason to retrieve results promptly, not a reason to wait until day seven. The available verified information does not establish whether the retention clock starts at upload, submission or completion. Confirm that timing before calculating deadlines. Seven-day retention also does not establish immediate erasure from every backup or processing provider. It is not, by itself, an archival or regulatory-compliance guarantee.
3. Make durable download part of the job lifecycle
Skavio supports idempotent job submissions, signed completion webhooks and authenticated result downloads. Use those capabilities to build an explicit handoff from processing to your own storage. A completion notification should trigger retrieval—not mark the entire business workflow as finished. Skavio’s documentation advises preserving results before expiry. Record processing completion and successful preservation as separate states in your application.
- Before upload, record a stable business-request ID and the original’s storage location.
- Submit idempotently and associate the returned job ID with that request.
- Validate completion webhook signatures according to the published contract.
- Download required outputs through authenticated access, then verify that the saved files are complete and readable.
- Record durable output locations against the request and job IDs before marking the handoff complete.
4. Control intake instead of retrying into a full store
For capacity planning, estimate retained source volume from incoming bytes and expected residence time, then allow headroom for existing data and uncertainty. This is an engineering estimate, not Skavio’s quota-accounting formula. Confirm what is counted before using it to decide whether another batch can be uploaded. Use bounded retries with backoff and jitter for transient failures. A submission timeout does not prove that nothing happened, so preserve the same submission identity when retrying an idempotent operation. A capacity rejection calls for investigation or a change in available capacity—not an endless retry loop. Do not assume that downloading outputs, completing a job or reaching an expiry immediately releases source-storage capacity. Cleanup eligibility, timing and accounting need confirmation.
5. Monitor preservation, not just processing success
Distinguish a completed job from an output safely preserved. Monitor pending downloads and their age separately from queued or active processing. Set alerts early enough to allow recovery, using confirmed retention timing rather than an assumed clock. Test failure paths before production. These are suggested acceptance tests, not claims about specific Skavio behavior:
- Concurrent uploaders approaching the company allowance.
- A downloader outage while processing continues.
- Duplicate completion notifications and repeated retrieval attempts.
- A partial local download that must not be marked as preserved.
- Recovery of outstanding outputs before their confirmed expiry.