Skip to main content
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 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: 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

​
Tasks

​
Notes

​
Clients

​
Prospects

​
Contacts

​
People

​
Households

​
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. 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.

​
Download the specification

Download the OpenAPI 3.1 webhook specification for the full event catalog and payload schemas. The HTTP endpoint reference uses a separate specification.