> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/document-ai/guides-1/webhooks-and-integrations.md). # Webhooks & Integrations Webhooks let teams receive document-processing results as soon as jobs finish. This page explains what webhook delivery does, when events fire, how retries work, and how to monitor or retrigger deliveries from the platform. {% hint style="info" %} Configure one or more HTTPS endpoints on your account. Every matching webhook event is sent to all configured URLs. {% endhint %}

Webhook Monitor — Pending, Processed, Failed and Total counts above the delivery table, each row showing webhook id, document id, status and attempt count

### What webhooks do Webhooks fire automatically when a document extraction, classification, or generation job moves from `Pending` or `Processing` into a terminal state such as `Processed` or `Failed`. Each delivery attempt is tracked so teams can monitor outcomes, inspect payloads, and manually resend events when needed. In the UI, deliveries are available in the Webhook Monitor, accessible from the sidebar platform area and from quick links on the home experience. | Capability | Description | Operational detail | | ---------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | Automatic delivery | Fires when extraction, classification, or generation jobs complete | Multi-document operations wait until all child items finish before the webhook is sent | | Retry with backoff | Failed deliveries retry automatically | Default behavior is 3 attempts with exponential backoff starting at 30 seconds and capped at 8 minutes | | Terminal failures | Some failures stop retries immediately | 4xx responses are treated as permanent failures for that destination URL | | Stale webhook recovery | Long-running stuck deliveries are retried | Processing items that remain stuck can be retried after 24 hours | | Manual retrigger | Users can resend a delivery on demand | Useful for downstream outages, endpoint fixes, or validation reruns | | Signed payloads | Webhook payloads are signed for verification | Signing uses HMAC-SHA256 with the account webhook private key | | Monitoring | Teams can list, filter, and inspect delivery attempts | Common filters include ID, document ID, status, and event type; pages support up to 100 items | {% hint style="warning" %} The Webhook Monitor status filter may include **Cancelled** in the UI even though the documented status values are `Pending`, `Processing`, `Processed`, and `Failed`. {% endhint %} {% hint style="warning" %} A webhook's Document ID can link back to the document's detail record in the processing workflow. For related processing behavior, see [Document Extraction](/document-ai/guides-1/document-extraction.md). {% endhint %} ### Workflow 1. **Configure** — add one or more webhook URLs to your account settings. 2. **Trigger** — a supported job completes and reaches a terminal processing state. 3. **Deliver** — the platform sends a signed payload to each configured endpoint, including an event identifier for idempotent handling. 4. **Retry on failure** — retryable failures are resent using exponential backoff. A 4xx response ends retries for that destination. 5. **Monitor** — users review delivery status and inspect payload, response, and timeline details. 6. **Retrigger** — users manually resend a webhook after a failure or after fixing a downstream issue. > Configure → Trigger → Deliver → Retry → Monitor → Retrigger ### Event coverage Completion events are emitted for the main document-processing collections below. | Event source | Fires when | | ----------------------- | ------------------------------------------------------------------------------------ | | Document Extraction | An extraction job completes, including single-document and multi-document processing | | Document Classification | A classification job completes | | Document Generation | A generation job completes | Frontend event labels may include `extraction`, `extraction-updated`, `processing-complete`, `processing-failed`, and `document-uploaded`. Everyone in the account can view Webhook Monitor. Delivery counts reflect account activity over time, so they are the same whichever role you sign in with. ### Other integrations Google OAuth is supported for authentication through ID token verification. At present, webhooks are the primary external integration mechanism for pushing processing outcomes into downstream systems. ### Related pages * [Document Classification](/document-ai/guides-1/document-classification.md), [Document Extraction](/document-ai/guides-1/document-extraction.md), and [Document Generation](/document-ai/guides-1/document-generation.md) each emit completion events. * [User Management](/document-ai/guides-1/user-management.md) covers account settings and signing-key context for webhook verification. * [Workspace](/document-ai/getting-started/workspace.md) gives operators a quick path into the monitor. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.uptiq.ai/document-ai/guides-1/webhooks-and-integrations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.