Salesforce doesn't have webhooks
There is no "add webhook" button in Setup. What Salesforce has is a family of eventing and integration features - each with different payloads, guarantees, and amounts of work - that can be assembled into webhook-like behavior. This page is the map: the six real options, what each actually gives you, and how to pick.
The six options
| Approach | Latency | Payload | Delivery guarantee | Effort |
|---|---|---|---|---|
| Poll the REST API | Minutes at best - you're on a timer | JSON you assemble from queries | None - missed windows are your problem; burns API request limits | Low to start, high to make correct (cursors, deletes, rate limits) |
| Outbound Messages | Near real time | SOAP XML | Retries up to 24h, then dropped, with no signature | Low (declarative) |
| Apex HTTP callouts | Near real time | Anything you build | Whatever you build - retries, queueing, and alerting are all Apex you own, inside governor limits | High, and it lives in your org |
| CDC + Pub/Sub API, self-hosted | Real time | Avro → your JSON | At-least-once from the bus. Everything after the subscriber is yours to build | Highest - gRPC subscriber, replay tracking, retries, monitoring |
| Generic iPaaS | Near real time | Vendor-shaped | Task-based, varies by plan, rarely signed raw payloads | Low–medium, per-task pricing |
| SFHooks | Real time (CDC) | Signed JSON, stable contract | At-least-once, 31 jittered retries, 14-day DLQ with replay, per-event history | OAuth in, point at your endpoint |
Category-level comparison - not claims about any specific vendor. "Effort" includes keeping it running, not just the first happy path.
How to choose in three questions
1. Is losing an occasional change acceptable? If yes (a convenience notification, say), Outbound Messages or an iPaaS task is fine. If a missed change means bad data downstream, you need real retry infrastructure and a dead-letter queue - that narrows it to self-hosted CDC or SFHooks. (New to Change Data Capture itself? The practical guide covers what the events contain and the operational realities.)
2. Does the payload land in your code or in a vendor's UI? If integrations live in your codebase - services that verify, transform, and act on events - you want raw, signed JSON. If business users assemble the automation, an iPaaS is genuinely the better tool.
3. Do you want to own a streaming subscriber? The Pub/Sub API is excellent - SFHooks is built on it. The question is whether the gRPC subscription lifecycle, replay-offset persistence, retry queues, and the dashboards on top are code your team wants to write and keep on-call for. Sometimes the answer really is yes. Here's the full list of what you'd be signing up for.
What a delivery looks like
However you get there, a Salesforce webhook should be boring on the receiving end: an HTTPS POST with JSON, a signature you can verify in four lines, and a delivery log you can point at when something looks off. That's the contract SFHooks ships - inspect a live payload and compute its signature in the playground, no account needed.
Frequently asked
Does Salesforce support webhooks natively?
No. Salesforce offers eventing features - Outbound Messages (SOAP), Platform Events, and Change Data Capture over the Pub/Sub API - but no native 'send my endpoint signed JSON when a record changes'. You assemble that from the pieces, use an integration platform, or use a dedicated service like SFHooks.
What's the fastest way to get JSON webhooks from Salesforce?
Connect your org to SFHooks over OAuth, enable Change Data Capture on the objects you care about, and point a webhook at your endpoint - most teams see their first signed delivery in under ten minutes, and a built-in test event lets you verify your handler before any real data flows.
Can I build Salesforce webhooks myself with the Pub/Sub API?
Yes - subscribe to Change Data Capture over gRPC, decode Avro, persist replay ids, and build the retry, dead-letter, and monitoring layers around it. It's real engineering with real upkeep. Whether that's worth owning is the build-vs-buy question.