API Webhook Status and Polling
How to plan asynchronous PDF parsing completion using status polling, and how to avoid assuming webhook delivery unless it is explicitly supported for your integration.
Async completion concept
Long-running PDF parsing is handled asynchronously. Submit the PDF, store the returned task_id, then poll the status endpoint until the task completes or fails.
Use polling as the baseline
Design your application around task status polling. This avoids depending on webhook behavior that is not part of the documented baseline integration path.
Webhook limitations
Do not design webhook-only ingestion unless PDFAccessibility.ai has explicitly enabled and documented webhook delivery for your account or integration. Until then, treat webhook callbacks as unavailable and use polling.
Implementation checklist
- 1Submit the parse task
- 2Store the task id
- 3Poll status by default
- 4Avoid webhook-only assumptions
- 5Make completion handling idempotent
Questions about API Webhook Status and Polling
Are webhooks required?+
No. Polling task status is the baseline async workflow. Do not assume webhook delivery unless it is explicitly supported and enabled for your integration.
What should a completion handler do?+
Fetch or store completed output, mark the document ready, and avoid duplicating work if the same completion signal is processed more than once.