Skip to main content

Streaming and asynchronous jobs

As in API, there are two different mechanisms:
  1. Response Streaming (/convert/stream): Progressive Markdown fragments while the server converts, reading the file direct from disk with Bun.file.
  2. 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.