Skip to main content
Entity webhooks notify your integration when an entity is created, updated, or deleted. Each endpoint selects its actions and either all supported entity types or a list of types. Reads do not produce events. Configure endpoints in Workspace Settings → Entity webhooks, or use the webhook API. Each workspace supports up to ten endpoints. Management requires an API key belonging to a workspace owner or Octave admin; changes, secret rotation, and test sends also require write API access. Read-only keys can list endpoints.

Supported entities

Products, services, solutions, core features, segments, personas, use cases, proof points, reference customers, competitors, alternatives, buying triggers, objections, skills, brand voices, motions, and motion playbooks. motion refers to the motion record. motion_playbook refers to a motion playbook record. Neither subscribes to all nested changes. ICPs, motion ICP cells, deprecated hypotheses, and legacy playbooks are excluded, including from all entity types. Tracked collection changes notify the collection owner. Separate graph edge changes and maintenance writes that bypass normal entity persistence are not included. Soft deletion emits entity.deleted; restoring an entity emits entity.updated.

Create an endpoint

Set entityTypes to null for all supported types. Empty action/type lists are rejected. The response contains endpoint and a one-time secret, plus _metadata. Store the secret securely. Listing or updating endpoints does not reveal it. To update, send the complete configuration plus oId to POST /api/v2/entity-webhook/update. Set enabled: false to pause. Delete with DELETE /api/v2/entity-webhook/delete?oId=whe_example.

Event payload

Notifications are small: fetch the entity using its type and ID for current content. A notification is not a full snapshot of the entity at that moment.
The event types are entity.created, entity.updated, and entity.deleted. changedFields names stored top-level fields or tracked collections; it is not a nested JSON diff. Revision history is asynchronous and does not cover every change. When an exactly correlated revision is available before the first attempt, the notification includes its revisionId, materiality (none, minor, or material), and materialitySource (deterministic or llm). Otherwise these fields are null. Null means unavailable, not insignificant. Retries preserve the payload for that endpoint.

Verify signatures

Every send uses HMAC-SHA256 with the endpoint secret: Verify the raw request bytes, before parsing JSON. Check the timestamp against a short tolerance to prevent replay, compare signatures in constant time, and deduplicate by event ID. For example, in Node.js:
Rotate a secret using POST /api/v2/entity-webhook/rotate-secret with { "oId": "whe_example" }. The new secret is shown once and applies to subsequent attempts immediately. Coordinate rotation with your receiver.

Send a test

Use Send test on a saved endpoint, or:
The receiver gets a signed event with test: true, the first configured action/type (persona for all types), and data.object.oId: "example_entity". Revision metadata is null. Do not try to fetch that example entity. The API responds with status, responseStatus, and error, plus _metadata; HTTP 200 alone does not mean the receiver accepted the test. Check status: "delivered".

Delivery behavior

A durable queue is written in the entity’s transaction, so rolled-back writes produce no notifications. A scheduler dispatches due deliveries every minute; background consumers claim and send them. Duplicate queue messages cannot claim the same dispatch twice, and active sends are protected from concurrent retries. A crash after your receiver accepts a request can still cause another delivery, so deduplicate the stable delivery ID. Delivery retries transient failures with backoff; duplicates and out-of-order events are possible. A permanently failing endpoint can exhaust its retry budget. Return a successful response promptly and process notifications asynchronously. Enabling an endpoint does not replay old changes. Pausing/deleting discards queued notifications when the worker reaches them. Changing filters affects future changes; queued notifications retain their original destination URL. Inspect Workspace Settings → Notifications for delivery receipts and failures. No ordering guarantee is made across endpoints.