POST the moment something changes.
Webhooks can be created and managed in two ways:
- By the Vendaze customer directly in the platform dashboard
- Via the public API using the
webhooks:managescope
How it works
- A webhook is created with a destination URL and the list of events to subscribe to
- When a subscribed event fires, Vendaze enqueues the delivery and sends a
POSTto that URL - Your server processes the payload and returns
2xxwithin 10 seconds
Managing webhooks via API
Webhooks created via the API are only visible to the OAuth app that created them. They do not appear in the Vendaze dashboard and cannot be managed by other apps, even if they access the same workspace.| Endpoint | Description |
|---|---|
GET /v1/webhooks | List webhooks created by your app |
POST /v1/webhooks | Create a webhook |
GET /v1/webhooks/:id | Get a webhook by ID |
PATCH /v1/webhooks/:id | Update a webhook |
DELETE /v1/webhooks/:id | Delete a webhook |
Authenticated deliveries
Whenauth_enable: true is sent on webhook creation, Vendaze generates a webhook_secret (format: whsec_...) and includes it in the POST /v1/webhooks response. Store it: it will be used to verify incoming deliveries.
Each delivery to your endpoint will include the Webhook-Signature header. See Signature verification for implementation details.
Changing auth_enable on an existing webhook affects the secret:
falsetotrue: a newwebhook_secretis generated and returnedtruetofalse: the existingwebhook_secretis permanently deleted
Payload
Every delivery is aPOST with Content-Type: application/json. The envelope structure is:
| Field | Type | Description |
|---|---|---|
id | string | Unique delivery ID. Use for deduplication. |
event | string | Event name, e.g. person.created |
version | string | Always v1 |
created_at | string | ISO 8601 UTC timestamp of when the event was dispatched |
<entity> | object | The entity data. The key matches the event type: person, company, deal, task, activity, tag, product, pipeline, or member |
Signature verification
Whenauth_enable is true, every delivery includes:
Available events
People
People
| Event | Trigger |
|---|---|
person.created | A person is created |
person.updated | A person is updated |
person.deleted | A person is deleted |
Companies
Companies
| Event | Trigger |
|---|---|
company.created | A company is created |
company.updated | A company is updated |
company.deleted | A company is deleted |
Deals
Deals
| Event | Trigger |
|---|---|
deal.created | A deal is created |
deal.updated | A deal is updated |
deal.stage_changed | A deal moves to a different stage |
deal.won | A deal is marked as won |
deal.lost | A deal is marked as lost |
deal.deleted | A deal is deleted |
Tasks
Tasks
| Event | Trigger |
|---|---|
task.created | A task is created |
task.updated | A task is updated |
task.completed | A task is marked as completed |
task.deleted | A task is deleted |
Activities
Activities
| Event | Trigger |
|---|---|
activity.created | An activity is logged |
activity.updated | An activity is updated |
activity.deleted | An activity is deleted |
Products
Products
| Event | Trigger |
|---|---|
product.created | A product is created |
product.updated | A product is updated |
product.deleted | A product is deleted |
Pipelines
Pipelines
| Event | Trigger |
|---|---|
pipeline.created | A pipeline is created |
pipeline.updated | A pipeline is updated |
pipeline.deleted | A pipeline is deleted |
Members
Members
| Event | Trigger |
|---|---|
member_invited | A member is invited to the workspace |
member_joined | A member joins the workspace |
member_removed | A member is removed from the workspace |
Usage
Usage
| Event | Trigger |
|---|---|
usage_logs.created | A usage log entry is recorded |
Retries and delivery guarantees
If your server does not return2xx within 10 seconds, Vendaze retries the delivery up to 3 times, each attempt delayed by 15 minutes. After all retries are exhausted, the event is permanently dropped. There is no suspension mechanism: missed deliveries are lost.
| Attempt | Delay |
|---|---|
| 1 (initial) | Immediate |
| 2 | 15 minutes after attempt 1 |
| 3 | 15 minutes after attempt 2 |
| 4 | 15 minutes after attempt 3 |
id field in the envelope.
Best practices
- Return
200immediately and process asynchronously. Any handler that takes more than 10 seconds will trigger a retry. - Reject missing or invalid signatures with
401. Never process a delivery from an authenticated endpoint without verifying the signature first. - Retain received payloads for at least 30 days to aid debugging and auditing.
- Return
200for unrecognized event types. New events will be added over time and silently ignoring them keeps your handler stable across API updates.