Skavio Processing API: what the 100-file and 500 MB upload limits mean
Before sending a multi-file workload to Skavio Processing API, check both the number of files and their combined size. The upload-batch limits are 100 files and 500 MB total—not 500 MB for each file. Build your integration around that distinction, then handle processing requests separately: passing the upload count-and-size checks does not automatically make a batch suitable for a processing job.
1. Check file count and total size independently
An upload group must satisfy both limits. Counting files without measuring their combined size misses oversized batches; measuring size without counting files misses collections of too many small documents. These illustrative calculations show why neither check can replace the other:
- 101 small files exceed the file-count limit, even if their combined size is well below 500 MB.
- 80 files of 7 MB each total 560 MB and exceed the size limit, despite staying below 100 files.
- 100 files of 4 MB each total 400 MB and clear these two checks only. Format, storage and operation-specific requirements still apply.
2. Build bounded upload groups before sending data
Create an inventory of local sources with a stable identifier and measured file size. Add files to an upload group while tracking its count and accumulated size. Start another group before adding a file would exceed either ceiling. Flag any source that exceeds the total size allowance on its own: moving it into a different group cannot make it smaller. As an integration precaution, choose a size target below the published ceiling rather than relying on exact-boundary acceptance. The documentation uses MB and MiB in different upload contexts, so confirm the byte definition and boundary behavior for your chosen route before hard-coding an exact threshold. Multipart boundaries and part headers also add transport bytes. It is not established whether Skavio counts that overhead against the source-size allowance; do not assume either accounting method.
- Measure the actual sources you intend to upload; do not rely on an average file size.
- Keep a manifest so responses can be mapped back to local files.
- Treat headroom as an integration choice, not as an additional Skavio limit.
3. Upload sources first; choose processing groups second
The documented sequence separates file transfer from processing: send sources to POST /v1/uploads using the multipart field files, then use the returned upload IDs with POST /v1/estimate and POST /v1/jobs. For multiple files belonging to one form field, multipart/form-data uses separate parts with the same field name. An illustrative curl fragment is `-F 'files=@first.pdf' -F 'files=@second.pdf'`. This demonstrates repeated files fields; it is not a complete or execution-tested API request. Preserve the relationship between each source and its returned upload ID. Then construct processing requests according to the selected operation’s requirements. The 100-file upload allowance does not establish that every operation accepts 100 sources in one job, or that each uploaded file becomes a separate job.
- Upload each bounded group and record the returned upload IDs.
- Estimate the intended processing request using the relevant upload IDs. Processing uses the shared company wallet.
- Submit the processing request idempotently. Submission reserves the measured quote; success charges once, and permanent failure releases the reservation.
4. Keep storage and processing limits in the preflight
Splitting a collection into smaller uploads addresses upload grouping, not every constraint on the workload. Sources still need to fit company storage and the requirements of the selected operation. A collection can pass the count-and-size checks yet remain unsuitable for the requested work.
- Company source storage: the allowance is 2 GB. Several individually compliant upload groups still need to fit within available company storage.
- PDFs: the published maximum is 100 pages per PDF. A small file size does not remove the page-count constraint.
- Media: duration limits are operation-specific. Skavio File Toolbox media processing has a two-hour maximum; check the selected operation rather than inferring duration support from file size.
5. Correct failed uploads instead of replaying them blindly
If an upload returns HTTP 413, inspect the response before retrying. The status means the request content is larger than the server is willing or able to process; resending an unchanged oversized request does not resolve a fixed size limit. For a temporary condition, the server may include Retry-After guidance. Use the response to distinguish the reported condition from your own preflight result. Keep upload recovery separate from job-submission retries. Skavio’s support for idempotent job submissions does not establish upload-request idempotency, atomic multi-file uploads or resumable transfer. If an upload outcome is ambiguous, do not assume that every source was accepted—or that none was. After processing completes, download results through authenticated requests and plan retrieval within the seven-day retention window. Your local manifest should connect the original source, its upload ID, the submitted job and the retrieved output.