Skip to main content

Streaming and asynchronous jobs

As in the rest of the SDKs, there are two different mechanisms:
  1. Response Streaming (/convert/stream, /convert/stream-from-url): Progressive Markdown fragments via callback.
  2. 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.