> ## Documentation Index > Fetch the complete documentation index at: https://docs.slant.app/llms.txt > Use this file to discover all available pages before exploring further. # Webhooks overview > Supported events, payload formats, and delivery handling for Slant integrations. Receive changes to Slant records without polling. Choose event types in your app's webhook endpoint configuration, then use the event reference to process each payload. ## Before you start The partner subscription flow requires an OAuth app and a connected user's OAuth access token. Personal access tokens cannot use `/v1/webhook_subscription`. Follow the [partner integration guide](/api-reference/partner-integrations#configure-webhook-delivery) to configure an endpoint, save its signing secret, and subscribe a connected user. Subscriptions cover the books that user can access within the authorized company. ## Shared subscription context Every OAuth app delivery includes these fields at the top level, alongside its event-specific fields: | Field | Meaning | | - | - | | `subscription_id` | The subscription that caused this delivery. | | `user_id` | The subscribed Slant user. | | `book_id` | The book containing the record. | | `company_id` | The company that owns the book. | All Slant record IDs are opaque strings. Use them as supplied in API requests. The event reference examples include subscription context so you can see the complete envelope. If two subscribed users can access the same book, your app receives a separate copy for each subscription. Those copies have distinct message IDs. Deduplicating by message ID does not combine overlapping subscriptions. ## Event catalog Each event page includes its trigger, payload schema, signing headers, and a complete JSON example. ### Meetings * [`meeting.created`](/api-reference/webhooks/meeting-created) * [`meeting.updated`](/api-reference/webhooks/meeting-updated) * [`meeting.deleted`](/api-reference/webhooks/meeting-deleted) * [`meeting.transcript_ready`](/api-reference/webhooks/meeting-transcript-ready) ### Tasks * [`task.created`](/api-reference/webhooks/task-created) * [`task.updated`](/api-reference/webhooks/task-updated) * [`task.completed`](/api-reference/webhooks/task-completed) * [`task.reopened`](/api-reference/webhooks/task-reopened) * [`task.deleted`](/api-reference/webhooks/task-deleted) ### Notes * [`note.created`](/api-reference/webhooks/note-created) * [`note.updated`](/api-reference/webhooks/note-updated) * [`note.deleted`](/api-reference/webhooks/note-deleted) ### Clients * [`client.created`](/api-reference/webhooks/client-created) * [`client.updated`](/api-reference/webhooks/client-updated) ### Prospects * [`prospect.created`](/api-reference/webhooks/prospect-created) * [`prospect.updated`](/api-reference/webhooks/prospect-updated) ### Contacts * [`contact.created`](/api-reference/webhooks/contact-created) * [`contact.updated`](/api-reference/webhooks/contact-updated) ### People * [`person.updated`](/api-reference/webhooks/person-updated) ### Households * [`household.tag_added`](/api-reference/webhooks/household-tag-added) ### Related records * [`related_record.created`](/api-reference/webhooks/related-record-created) * [`related_record.updated`](/api-reference/webhooks/related-record-updated) * [`related_record.destroyed`](/api-reference/webhooks/related-record-destroyed) ## Payload conventions Meeting, task, and note events include `event_type` and a top-level record `id`. Created and updated events include a nested snapshot; `.deleted` events contain identifiers only. Note events also include applicable parent IDs. CRM, household tag, and relationship events retain their own formats and do not include `event_type`. If your handler needs their exact event names, configure separate endpoint URLs filtered to individual event types. Relationship deletion uses `related_record.destroyed`; meeting, task, and note deletion uses `.deleted`. CRM update events are grouped using a 60-second debounce window. Their `changed_fields` lists accumulated field names, not previous values or a patch. Creating a meeting, task, or note does not emit extra updated events for its initial rich text, tags, or meeting links. Later changes to those fields emit updated events. Completing or reopening a task also emits `task.updated`. Scheduled and unapproved tasks do not emit task events. ## Receive and process deliveries 1. Verify the raw request body using the endpoint signing secret and the `svix-id`, `svix-timestamp`, and `svix-signature` headers. Use a [Svix verification library](https://docs.svix.com/receiving/verifying-payloads/how). Parsing and re-serializing JSON before verification changes the signed content. 2. Persist or enqueue the accepted delivery, then return a successful `2xx` response promptly. Svix handles delivery retries. 3. Make processing idempotent using `svix-id`. Do not assume exactly-once delivery or depend on delivery order. Meeting, task, and note snapshots are read asynchronously when prepared for delivery, not captured at the instant of the triggering change. A `task.completed` event can therefore contain a task that has since been reopened. These events do not include `changed_fields` or previous values. Use the nested record's `updated_at` to avoid replacing a newer local version with an older snapshot. Fetch current state when you need to reconcile deliveries or resolve ordering. A fetch can return `404` if the record was deleted after an earlier event was queued. For `.deleted`, remove your local copy. Meeting, task, and note snapshots respect the subscribed user's record access; deletion notifications go to the book's eligible subscriptions. Messages already submitted for delivery may still arrive after unsubscribe or loss of access. Use the webhook portal's **Logs** to inspect messages and delivery attempts, and **Event Catalog** to view available event types. Manage subscriptions and disconnection through the [partner integration guide](/api-reference/partner-integrations#disconnect-and-unsubscribe). ## Download the specification Download the [OpenAPI 3.1 webhook specification](/api-reference/webhooks.yaml) for the full event catalog and payload schemas. The [HTTP endpoint reference](/api-reference/overview) uses a separate specification. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.