Async and asynchronous jobs
Java’s SDK exposes two independent forms of non-blocking conversion:
- API asynchronous local (
convertBytesAsync): Your own code does not block the thread while waiting for the HTTP response, using CompletableFuture.
- Jobs due to saturation (
202): when all server backends are busy, the request is queued server-side and responds 202 with a job_id. See GET /jobs/{id}.
Both mechanisms are independent: you can use blocking methods (convertFile, convertBytes) with autoPoll handling 202 internally, or use convertBytesAsync to not block your thread while SDK resolves everything (including polling an eventual job).
CompletableFuture with convertBytesAsync
Componer varias conversiones en paralelo
Aggressively parallelizing requests can trigger 429. Limit concurrency (for example with Semaphore or batch processing) if you convert many documents at once.
Jobs due to saturation (202)
By default, convertFile, convertBytes, convertBytesAsync and convertFromUrl handle 202 transparently (ConvertOptions.autoPoll is true by default).
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 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.