Streaming and asynchronous jobs
As in API, there are two different mechanisms:
- Response Streaming (
/convert/stream): Progressive Markdown fragments while the server converts, reading the file direct from disk with Bun.file.
- Jobs due to saturation (
202): when all backends are busy, the request is queued and responded to 202 with a job_id. See GET /jobs/{id}.
Streaming with convertStream
convertStream is a AsyncGenerator<string> — use it with for await...of. Internally it opens Bun.file(path) and streams it to the body of POST /convert/stream, so the entire file is never loaded into memory before being sent.
streamSlimStrategy
"off": pure streaming per page, without noise detection. TTFB minimum.
"sampled" (default): Sample the first few pages, then output per page.
"full": materializes the entire document before issuing. Better cleaning, worse TTFB.
See Parameters.
Jobs due to saturation (202)
By default, convertFile, convertBytes and convertFromUrl handle 202 transparently (autoPoll: true on the client):
Poll manual
waitForJob is equivalent to calling getJob in a loop respecting retry_after_seconds, but encapsulated.
Under normal load conditions you won’t see 202 — it only happens when all backends are saturated. autoPoll: true (the default) already covers it without additional code in most cases.
Results for completed jobs expire in approximately 1 hour. If you save a jobId and receive 404 when querying it, resend the original conversion.