> ## Documentation Index > Fetch the complete documentation index at: https://www.fluenterp.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Webhook event catalog > Understand every document, approval, and API-run event emitted by Fluent. Fluent event names follow `.` where possible. Document lifecycle events add verbs such as `created`, `updated`, `deleted`, and `restored` for changes that are not document statuses. ## Document events Document events apply to documents created from any source, including API runs, email, chat, and schedules. | Event | Emitted when | | ------------------------------- | ----------------------------------------------------------------------------- | | `document.created` | A real document is created. | | `document.updated` | A person saves changes or restores an earlier document version. | | `document.pending_approval` | The document enters or re-enters its approval flow. | | `document.approved` | Every approval stage clears, or an administrator force-approves the document. | | `document.rejected` | The document's approval flow is rejected. | | `document.waiting_for_receipts` | An AP invoice is waiting for matching receipt records. | | `document.processed` | Fluent writes the document to its configured system of record. | | `document.error` | Document processing fails. Read `data.document.error`. | | `document.deleted` | The document moves to trash, including through an automatic retention policy. | | `document.restored` | The document is restored from trash. | ### Creation and initial status Every document insertion emits `document.created`. If the document is created directly in another subscribed state, Fluent immediately emits the matching status event as well. For example, a quota or intake failure can create a document whose initial status is `error`. Consumers receive `document.created` followed by `document.error`. Both events have `previous_status: null`. Most documents begin in `processing`, which has no event of its own, so they initially emit only `document.created`. ### Updates `document.updated` represents a meaningful human change: * `update.trigger: "user_edit"` means a person saved edited document data. * `update.trigger: "rollback"` means a person restored an earlier version. Automated extraction, tools, expressions, and other pipeline writes to `document_data` do not emit `document.updated`. ### Approval outcomes `document.pending_approval`, `document.approved`, and `document.rejected` describe the approval flow as a whole. They are separate from the per-approver `approval.*` events. Two transitions are especially important: * Force approval emits `document.approved` without requiring preceding `approval.approved` events for every stage. * Reopening a rejected document emits `document.pending_approval` again. Therefore, `document.rejected` is not necessarily the document's final event. ### Processing, trash, and retention `document.processed` confirms that Fluent wrote the document to the configured system of record. An agent run can complete before this happens when the document still requires review or approval. `document.deleted` represents a soft delete. It can be initiated by a person, an API request, or the team's document-retention policy. Use the included `document.status` to distinguish an in-flight cancellation from archival of an already processed document. A later restore emits `document.restored`. Permanent deletion after the trash-retention period does not emit another event. ## Approval events Approval events describe one approval unit at one stage. Subscribe to them when your application displays reviewer progress or needs individual votes. If you only need the overall verdict, use the document approval events instead. | Event | Emitted when | | -------------------- | -------------------------------------------------------------------- | | `approval.requested` | An approver is asked to review one stage. | | `approval.approved` | One approver approves their assigned stage. Other stages may remain. | | `approval.rejected` | One approver rejects with an optional note. | | `approval.skipped` | An approval unit does not apply and no vote will occur. | Each event includes `stage_name`, `stage_position`, `stage_count`, and an approval status. A human vote can include a `note`. For `approval.skipped`: * `approver` can be `null` when the approval unit matched nobody. * `note` is `null`. * `reason` can explain why the unit was excluded. Do not leave a skipped unit displayed as awaiting review; it will never receive a vote. ## API-run events Run events apply only to runs started through the public agent API. Runs started internally from email, chat, schedules, or other product workflows do not emit `run.*` events. | Event | Emitted when | | --------------- | ----------------------------------------- | | `run.completed` | The API run finishes successfully. | | `run.failed` | The API run fails. Read `data.run.error`. | | `run.cancelled` | The API run is cancelled. | A run can produce zero, one, or many documents. Terminal run events include the complete `document_ids` list, which can be empty. A successful text-only run, for example, can emit `run.completed` without any document event. Run completion and document processing are different milestones. `run.completed` means the agent finished its work; a resulting document may still be a draft, awaiting approval, waiting for receipts, or ready to process. ## Events that are not emitted Fluent does not currently emit events for transient `processing` or `draft` document states. These states do not indicate that an external system should act, and omitting them avoids a high-volume stream of intermediate pipeline updates. ## Forward compatibility Webhook payloads are additive. Fluent can add fields and event types without changing the webhook version. Consumers should: * Ignore payload fields they do not recognize. * Return `2xx` for unknown event types after recording them. * Subscribe to **All events** only when the consumer safely handles unknown types. A wildcard subscription receives future event types automatically. A list of individually selected event types does not.