Webhook

A webhook is an automated callback: when a document processing job finishes, the system sends an HTTP POST to a URL you specify, carrying the extracted data or a status update. It removes the need to keep asking "is it done yet?" Instead, your application waits and reacts only when there is something to react to.

How it works

In a document pipeline, you register a webhook URL when you submit a document (or once, at the account level, for all jobs). The extraction engine processes the file: classification, layout analysis, key-value extraction, validation rules, whatever the pipeline requires. Once it reaches a terminal state (success, failure, or needs review), the system builds a payload, usually JSON, containing the extracted fields, a confidence score, and a job identifier, then sends it to your endpoint.

Your server needs to do three things reliably: respond quickly (typically within a few seconds) with a 2xx status code, verify the request actually came from the vendor (a signature header, not just the URL being secret), and process the payload asynchronously rather than inside the request handler. Most providers retry failed deliveries with backoff, so your endpoint should be idempotent: processing the same job ID twice should not create duplicate records.

Webhooks work well for asynchronous, variable-length jobs like OCR or LLM-based extraction, where processing time depends on document complexity. They are the opposite of polling, where your application repeatedly calls an API to check job status. Polling wastes requests and adds latency; webhooks push data the moment it exists.

Why it matters for document processing

Document extraction rarely finishes instantly, especially for multi-page contracts or batches of invoices. Webhooks let you build a pipeline that reacts the moment data is ready, rather than one that checks in on a timer and wastes cycles or adds delay. This matters for straight-through processing: an invoice validated and approved without a human touch needs its result routed to the ERP system within seconds, not minutes.

Reliability matters as much as speed. A missed or dropped webhook call can leave a claim or invoice stuck with no one aware it happened. Good implementations log every delivery attempt, expose a dashboard or audit trail for replay, and let you re-fetch results via a regular API call as a fallback. When evaluating a document AI vendor, ask how they handle webhook retries, signature verification, and payload versioning: those details decide whether your integration is solid or fragile.

Related terms

• Straight-through processing (STP)
• Confidence score
• Audit trail
• Data extraction
• Build vs buy IDP

FAQ

What happens if my server is down when a webhook fires?

Most document processing platforms retry failed deliveries with exponential backoff, often over several hours, and mark the job as delivered only after a successful response. If retries run out, you should still be able to fetch the result manually through a status API. Always build that fallback; don't assume webhooks alone are enough.

Should I use webhooks or polling for document extraction?

Use webhooks for production pipelines: they cut latency and reduce unnecessary API calls. Polling is fine for quick tests, debugging, or environments where you cannot expose a public endpoint (behind a strict firewall, for instance). Some teams use both: webhooks as the primary path, polling as a periodic reconciliation check for jobs that might have been missed.