Streaming and asynchronous jobs
As in the rest of the SDKs, there are two different mechanisms:
- Response Streaming (
/convert/stream, /convert/stream-from-url): Progressive Markdown fragments via callback.
- Jobs due to saturation (
202): the request is queued when all backends are busy. See GET /jobs/{id}.
Streaming with convertStream
markpdf-cpp does not expose coroutines by default (to maintain C++17 compatibility); streaming is modeled with a callback invoked in the same thread for the duration of the underlying HTTP request (implemented with CURLOPT_WRITEFUNCTION):
Run in a separate thread (do not block the main thread)
Client is safe to use from another thread as long as you don’t share the same call in progress between threads.
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 (opts.autoPoll = true), convertFile and convertFromUrl block the thread that calls them until the job finishes:
Poll manual
Under normal load conditions you won’t see 202 — it only happens when all backends are saturated. autoPoll = true (the default) already covers it transparently, included in the thread that makes the call.
Results for completed jobs expire in approximately 1 hour. If you save a jobId for later and getJob returns 404 (mapped to MarkpdfError with statusCode == 404), resend the original conversion.