API-first document pipelines without a local PDF stack

Most product teams eventually need merge, convert, OCR, or accessibility checks. Shipping Ghostscript, Chromium, LibreOffice, and Tesseract inside your API tier multiplies CVE surface, memory spikes, and release risk.

Apilyn inverts the dependency: your service orchestrates jobs against a stable HTTP contract. Workers run in isolated pools (pdf-core, ocr, office-core, web-core) with prlimits and queue visibility tuned per pool.

The canonical async flow

Create an upload intent, stream bytes to object storage, complete the upload, then POST a job with the pipeline name and parameters. Poll or subscribe via webhooks when the job reaches a terminal state. Downloads are short-lived signed URLs—never pass raw storage keys to clients.

POST /v1/uploads/intent
POST /v1/uploads/{id}/complete
POST /v1/jobs  { "pipeline": "pdf.merge", "inputs": [...] }
GET  /v1/jobs/{id}
POST /v1/webhooks/endpoints

Design for idempotency and observability

Use idempotency keys on job creation for retried client paths. Correlate your request ID with Apilyn job IDs in structured logs. When a stage fails, the public error envelope includes a stable code—map it in your runbooks instead of parsing stack traces from workers you do not control.

For multi-step business processes (onboarding packets, compliance packets, monthly statements), model each step as an explicit job with webhook fan-out rather than one mega-pipeline. You retain clearer retries and billing attribution per stage.