OWASP REST Security Cheat Sheet

Skavio Processing API gives backend teams one integration surface for OCR, PDF tools, image and media processing, Flow extraction, Transcribe and Meeting reports. The useful common ground is the job lifecycle: upload sources, estimate credits, submit, monitor and download. Reuse that orchestration while keeping each operation’s inputs, settings and outputs explicit.

Choose the output before choosing the operation

Start with what your application needs to receive—not just the source file’s extension. A scanned invoice might require readable text, an editable document or structured fields for a downstream business process. Those are different jobs, even when they begin with the same PDF. OCR produces text or document output. Skavio Flow extracts custom fields and line items into XLSX, CSV or JSON, with source evidence and review warnings. Skavio Transcribe produces a transcript, while Skavio Meeting adds speaker-aware reporting, including summaries, decisions, action items and open questions. For file transformations, documented selectors include pdf-merge, image-edit, audio-trim and video-resize; transcribe and meeting select the corresponding recording workflows. Settings belong in options, but accepted sources and source counts differ by operation. One API does not mean one interchangeable payload—or automatic chaining of several operations into a single job.

Use OCR when the required output is recognized text or an OCR document.
Use Flow when the required output is custom structured business data.
Use PDF, image or media tools for a supported file transformation.
Use Transcribe for a transcript; use Meeting when the recording also needs speaker-aware reporting and follow-up material.

Build one upload-to-download lifecycle

Keep authentication and processing requests in your backend. Skavio supports scoped API keys and company-isolated jobs. Use HTTPS and keep credentials out of URLs, where logs may capture them. Inspect the developer documentation at https://www.skavio.eu/api/docs/ and the published OpenAPI contract at https://www.skavio.eu/api/openapi.json before implementing request bodies. Use those references for exact upload fields, operation options and result references rather than guessing a payload. OpenAPI provides a language-independent API description that can support client generation and testing.

Upload: POST /v1/uploads with supported sources, following the documented upload schema.
Estimate: POST /v1/estimate for the selected operation and options. Present or evaluate the server quote before submission.
Submit: POST /v1/jobs with a persisted Idempotency-Key. Submission reserves the measured credit quote.
Monitor: GET /v1/jobs/{id}, or handle a verified completion webhook. Acceptance is not completion: an HTTP 202 response does not establish that outputs are ready.
Download: after successful completion, retrieve outputs through authenticated result downloads using the documented result references.

Budget by operation, not by job count

The API and Skavio’s web processing tools draw from one company Pricing V2 wallet. That gives the integration a shared balance, not a flat price for every job. Page count, source size, duration and the selected operation determine the quote. Submission reserves the measured quote; success charges once, and permanent failure releases the reservation. Prepaid credits do not expire, and monthly credits roll over. Use the server quote for the actual submission and GET /v1/pricing for the published pricing schedule. As an illustrative calculation, a 12-page, 8 MB PDF processed under the file-work rate uses the larger of one started 25 MB unit and two started 10-page units: 4 credits. OCR TXT for 12 pages is 36 credits; Flow extraction is 300 credits. These are different outputs, not interchangeable prices for the same work. Confirm the selected job’s server quote rather than treating this illustration as a completed API test.

Flow: 25 credits per page, minimum 25 per document.
OCR TXT: 3 credits per page, minimum 3. OCR DOCX or PDF: 10 credits per page, minimum 10.
File work: 2 credits per started 25 MB or per started 10 PDF pages, using the larger basis per source; minimum 2.
Media processing: 4 credits per started minute, minimum 4.
Transcribe: 8 credits per started minute, minimum 8.
Meeting: 15 credits per started minute, minimum 15.

Make retries safe—and completion verifiable

A submission timeout creates uncertainty: your application may not know whether the server accepted the job. Persist the Idempotency-Key before submitting so an identical retry reuses the job instead of creating another submission. Changed parameters with the same key return 409. An intentional retry after terminal failure requires a new key. Treat completion webhooks as notifications that must be verified. Delivery is at least once, so duplicate events are possible. Verify the signature against the raw request body, perform the documented timestamp checks and deduplicate events before triggering downstream actions. Keep your own submission record with the operation, options, quote and resulting job identifier. That gives the application a clear basis for status checks and output handling when a network request is interrupted.

Retry an uncertain submission with the same key and unchanged parameters.
Use a new key for a deliberate new job after terminal failure.
Deduplicate verified completion events before triggering downstream actions.
Keep API credentials server-side; do not expose them in browser code or URLs.

Finish with output validation, not just a successful status

Check limits before uploading: the total upload limit is 500 MB, PDFs are limited to 100 pages, and Transcribe or Meeting recordings to 10 hours. File Toolbox media has a separate two-hour maximum. Do not assume that every operation accepts the same source types or settings. After success, download outputs before the applicable retention period expires and store them according to your own retention requirements. Validate the result your downstream process actually needs. A successful job is not the same as an approved invoice record or a checked meeting decision. For Flow, review dates, totals and line items using the available evidence and warnings before export or downstream use. For Meeting, check decisions, action items and follow-up drafts before sharing them. The integration can reuse one lifecycle while preserving these task-specific review steps. For a first implementation, test one supported source end to end: obtain the quote, submit with idempotency, observe completion and download an authenticated result. Expand to additional operations only after checking their inputs and outputs against the contract. Start at https://www.skavio.eu/api/ to create a company API key and choose your first supported file.

Reuse the job lifecycle—not the assumption that every operation accepts the same input.

Sources

Skavio Processing API — The supplied research corroborates processing families, shared company credits and quote-based billing.
Skavio Processing API developer documentation — The supplied research documents the upload, estimate, submission and monitoring sequence; operation options; idempotency behavior; authenticated downloads; webhook handling; and relevant limits.
Skavio Processing API OpenAPI contract — Supplied official contract URL for checking exact request and response schemas before implementation.
OpenAPI Specification 3.1.1 — Describes a language-independent HTTP API contract and its use in documentation, client generation and testing; not cited as the latest specification.
OWASP REST Security Cheat Sheet — Supports HTTPS, keeping credentials out of URLs and distinguishing HTTP 202 acceptance from completed processing.

Open Skavio Processing API, create a company API key and test one supported file