CRM webhooks that tell your systems what changed, without polling
CRM webhooks let you choose the events a system cares about, and DigiPix Flow posts each one to your HTTPS endpoint, signed so you can prove it came from us. Failed deliveries are retried, logged with the reason and can be replayed, so an outage on your side never means a missed win.
- Ten lead, contact, company and deal events
- Every delivery signed with HMAC-SHA256
- Retried, logged and replayable
- events to subscribe an endpoint to
- 10
- delivery attempts before a delivery is set aside
- 5
- to replay a delivery that failed
- 1 click
What every webhook delivery carries
- EventWhat happened, such as deal.won
- RecordThe type and id of what changed
- DataThe details of the change, as JSON
- SignatureHMAC-SHA256 over the timestamp and body
- Delivery idOne id per delivery, for your logs
- Correlation idTies the event back to what caused it
Checking every few minutes for nothing
A script asks the CRM whether anything has changed, over and over, all day. Most answers are no, the useful ones arrive late, and the job quietly stops when a password changes or a server restarts.
A won deal nobody else hears about
Sales marks the deal as won, but onboarding, finance and the delivery team find out from a message in a group chat, or not at all. The customer waits for a kickoff call that nobody knew to book.
Requests you cannot verify
Anything on the internet can post to a URL. Without a signature and a timestamp to check, an endpoint cannot tell a genuine event from a forged or replayed one, so teams either trust everything or build nothing.
Subscribe to the moments that matter
Pick from ten events across leads, contacts, companies and deals: a record created or updated, a deal created, moved to another stage, won or lost. Each endpoint receives only the events it is subscribed to, so your finance system can listen for won deals while a marketing tool hears about new leads.
- Lead and contact created or updated
- Company created or updated
- Deal created, stage changed, won or lost
- Each endpoint chooses its own events
Add an endpoint in under a minute
Paste the HTTPS address that should receive events, tick the events it needs and save. DigiPix Flow shows the endpoint's signing secret once so you can store it beside your code. Addresses on private networks are refused, and each endpoint can be switched off and on again without deleting it.
- A public HTTPS address for each endpoint
- Its own signing secret, shown once
- Private network addresses refused
- Switch an endpoint off without deleting it
A small, predictable JSON body
Every delivery is a POST with the same shape: the event name, the kind of record and its id, the details of the change and a correlation id. Headers carry the event name and a unique delivery id too, so your code can route on the header and use the delivery id to ignore a message it has already handled.
- The same JSON shape for every event
- Record type and id on every delivery
- A unique delivery id in the headers
- A correlation id to trace the cause
Signed webhooks: prove every request came from DigiPix Flow
Each delivery is signed with HMAC-SHA256 using the endpoint's secret, over the timestamp and the exact body. Your endpoint recomputes the signature, compares it and checks the timestamp is recent, which rejects forged requests and old ones replayed by someone else. Rotate the secret whenever your policy calls for it.
- HMAC-SHA256 over the timestamp and body
- A timestamp header to reject stale requests
- A versioned signature header, starting at v1
- Rotate an endpoint's secret from Settings
A brief outage doesn't cost you an event
Any 2xx response within ten seconds counts as delivered. Anything else, a timeout, a 500 or a refused connection, is tried again after one minute, then two, four and eight, for five attempts in all. A delivery that still fails is set aside as dead-lettered, and your admins are told the endpoint is failing.
- Any 2xx within ten seconds is delivered
- Five attempts, waiting longer each time
- Undeliverable events set aside, not dropped
- Admins told when an endpoint is failing
See exactly what was sent, and what came back
Every delivery appears in the endpoint's log with its event, status, number of attempts, the response code and the last error. Filter to pending, delivered, failed or dead-lettered deliveries to find a problem quickly, instead of asking a developer to search server logs on the other side.
- Event, status and attempts on every row
- The response code and last error shown
- Filter by pending, delivered or failed
- Dead-lettered deliveries kept for review
Fixed the endpoint? Send it again
Once your endpoint is healthy again, replay any delivery that failed, was dead-lettered or has been stuck waiting for more than an hour. The same event goes out again, freshly signed, and its new result appears in the log, so you can recover from an outage without asking anyone to re-enter data.
- Replay failed and dead-lettered deliveries
- Deliveries stuck for over an hour included
- The same event, freshly signed
- The new result recorded in the log
An endpoint that's gone stops costing you
When an endpoint has failed twenty deliveries in a row, all the way to dead letter, DigiPix Flow switches it off and tells your admins why, rather than retrying into nothing. Turn it back on from Settings when it is fixed. Failure notices arrive at most once a day for each endpoint, so a bad night is one message.
- Switched off after 20 dead-lettered deliveries
- Admins told why it was switched off
- Turned back on from Settings in a click
- At most one failure notice a day per endpoint
From an endpoint to your first event, in five steps
- STEP 01
Add an endpoint
Paste your HTTPS address and store the signing secret it shows.
- STEP 02
Choose events
Tick the lead, contact, company or deal events it should receive.
- STEP 03
Verify signatures
Recompute the HMAC and check the timestamp before trusting an event.
- STEP 04
Act on the event
Start onboarding, update finance or notify a team when it arrives.
- STEP 05
Watch the log
Check deliveries, replay failures and rotate the secret as needed.
Webhooks vs polling scripts
| What it covers | Polling scripts |  DigiPix Flow |
|---|---|---|
| How changes reach you | A script asks again and again | DigiPix Flow posts each event to you |
| Delay | However long until the next check | Sent once the change is saved |
| Proving the source | Whatever the script trusts | An HMAC-SHA256 signature and timestamp |
| When your system is down | Changes missed until someone notices | Five attempts, then kept for replay |
| Finding a problem | Searching server logs by hand | A delivery log with status and errors |
| A broken destination | The job fails quietly for weeks | Admins told, and the endpoint switched off |
| Choosing what to send | Export everything and compare | Only the events each endpoint needs |
Webhook questions, answered
Which events can we subscribe to?
Ten: lead created and updated, contact created and updated, company created and updated, and deal created, stage changed, won and lost. Each endpoint chooses the events it wants.
What does a delivery look like?
An HTTPS POST with a JSON body holding the event name, your workspace id, the kind of record and its id, the details of the change and a correlation id. Headers carry the event name, a unique delivery id, a timestamp and the signature.
How do we verify a webhook came from you?
Join the X-Digipix-Timestamp header, a full stop and the raw request body, compute an HMAC-SHA256 of that string with the endpoint's signing secret, and compare it with the value after v1= in the X-Digipix-Signature header. Reject the request if they differ or if the timestamp is too old.
What counts as a successful delivery?
Any 2xx response returned within ten seconds. Do the heavy work after you respond, so a slow task on your side does not turn into a failed delivery and a retry.
What happens when our endpoint is down?
The delivery is tried again after one, two, four and eight minutes, five attempts in all. If every attempt fails it is dead-lettered and kept in the log, and your admins are told the endpoint is failing. You can replay it once the endpoint is back.
Could we receive the same event twice?
Yes, for example when a response is lost after your system has already processed it, or when you replay a delivery. Use the X-Digipix-Delivery header to recognise a delivery you have already handled.
Why was our endpoint switched off?
An endpoint is switched off automatically after twenty deliveries in a row have been dead-lettered, and your admins are told. Fix the endpoint, switch it back on in Settings and replay the deliveries you need.
Can we rotate the signing secret?
Yes. Rotate it from the endpoint in Settings and store the new secret, which is shown once. Deliveries from then on are signed with the new secret.
Who can manage webhooks?
People whose role includes permission to manage webhooks. How many endpoints a workspace can have depends on its plan.
Something we haven't covered? Talk to an expert
Keep exploring
Visit the blog- INTEGRATIONSCRM API for lead intakeSend leads into DigiPix Flow with scoped keys and safe retries.See the integration
- INTEGRATIONSLead capture APIThe lead endpoint in detail: fields, consent, duplicates and where leads land.See the integration
- PRODUCTSales pipelineThe stages, gates and approvals behind every deal event you receive.See how it works
- PRODUCTLead inboxWhere new leads land before the first lead event is sent.See how it works
- FEATURESAutomationWorkflows and sequences that act inside DigiPix Flow itself.Explore features
- INTEGRATIONSCRM REST APIThe other half of the developer story: create leads in DigiPix Flow from any app.See the integration
GUIDECRM Migration Checklist: Move From Spreadsheets or Another CRM Without Losing DataA step-by-step crm migration checklist for moving from spreadsheets or another CRM: audit your data, map every field, clean duplicates, run a test import, then plan the cut-over.Read the guide
GUIDEDuplicate Customer Records: Why the Same Buyer Appears Three Times, and How to Fix It for GoodDuplicate customer records creep in from ad forms, phone calls and old spreadsheets until one buyer has three records and two reps calling. This guide shows where they come from, how to merge them safely and how to stop new ones at the door.Read the guide
Let the rest of your business hear about every won deal
Talk to an expert — bring the systems that need to know when a lead arrives or a deal closes, and see the first signed event land.
- A real person, not a bot
- Bring your developer
- See a signed event arrive