Streaming and asynchronous jobs
There are two different “async” mechanisms in API, and SDK handles them separately:
- 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.
- 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:
- Read
job_id and retry_after_seconds of the answer.
- Sleep
retry_after_seconds (5s by default).
- Llama
GET /jobs/{job_id}.
- Repite mientras
status sea "queued" o "processing".
- 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.