Skip to main content

Streaming and asynchronous jobs

There are two different “async” mechanisms in API, and SDK handles them separately:
  1. Response Streaming (/convert/stream, /convert/stream-from-url): The server outputs the Markdown in progressive chunks while converting, to lower the TTFB in large documents.
  2. Saturation Jobs (202): When all backends are busy, any conversion endpoint queues the request and responds 202 with a job_id to query later. See GET /jobs/{id}.

Streaming with convert_stream

convert_stream returns a Iterator[str] iterator; each element is a Markdown fragment, not necessarily a complete line or page. Concatenate them in order to reconstruct the document.

stream_slim_strategy

Controls how repeated headers/footers are cleaned up without sacrificing too much TTFB:
  • "off": pure streaming per page, without noise detection. TTFB minimum.
  • "sampled" (default): Sample the first few pages for noise, then output per page.
  • "full": materializes the entire document before issuing. Better cleaning, worse TTFB.
See Parameters.

Jobs due to saturation (202)

By default, convert_file and convert_from_url handle 202 transparently:
Internally, if the server responds 202, the SDK:
  1. Read job_id and retry_after_seconds of the answer.
  2. Sleep retry_after_seconds (5s by default).
  3. Llama GET /jobs/{job_id}.
  4. Repite mientras status sea "queued" o "processing".
  5. Returns body when status == "completed", or throws MarkpdfJobFailedError if status == "failed".

Poll manual

If you prefer to control the loop yourself (for example, to show progress in a UI), disable auto-poll:
Under normal load conditions you will never see 202 — it only happens when all backends are saturated. You don’t need to design your application assuming it will always happen; auto_poll=True (the default) already covers it without additional code.
Results for completed jobs expire in approximately 1 hour. If you save job_id for later reference and receive 404, resend the original conversion.