Sometimes building it is right
If you have an eventing platform already, compliance rules that keep third parties out of the data path, or the use case is core enough to deserve a dedicated team - build. The Pub/Sub API is well designed and the documentation is decent. This page is the part the quickstart doesn't cover: what the subscriber you'll own actually has to handle. We know because we handle it - this list is our scar tissue, not speculation.
The checklist you're signing up for
| Layer | What has to work |
|---|---|
| Subscription | A long-lived gRPC/HTTP-2 stream per org. Subtlety: the stream must be opened and read in the same process - frames route to the opener, and getting it wrong doesn't error, it silently drops every event. |
| Liveness | Idle CDC streams are quiet for long stretches, and a dropped connection often dies silently. You'll need keepalive pings (client libraries commonly default to none) and a watchdog tuned to the bus's empty-keepalive cadence to detect a dead stream. |
| Reconnection | Exponential backoff - but reset it carefully: the bus can accept a subscribe and only then close the stream (bad auth does this), so resetting backoff on subscribe success turns a revoked token into a reconnect hammer. |
| Replay | Persist the replay id continuously so restarts resume instead of rewinding. Handle the ~72-hour buffer: expire gracefully, record what window of events may have been missed, and surface it - silently resuming from latest is data loss with no witness. |
| Schema | Avro decoding with a schema cache (events reference schema ids, so fetch each schema once, not per event) and tolerance for schema evolution. |
| Gap events | Under load the bus can emit gap/overflow events carrying no field data - just record ids. Reconciling them means re-fetching the live records over REST and merging, with its own failure handling. |
| Delivery | Everything after the subscriber: HMAC signing with secret rotation, retry queues with jittered backoff, a dead-letter queue that's complete by construction, per-endpoint health so one dead receiver can't drown the rest, and SSRF-safe egress if URLs are user-supplied. |
| Observability | Per-event delivery history, latency percentiles, and alerting on stream health - the difference between "it's down" and knowing what, since when, and what to replay. |
Each row is table stakes, not gold plating - every one exists because its absence loses or falsifies data eventually.
The honest math
A capable engineer gets a happy-path consumer running in a week or two. The list above is what turns that into months, and the maintenance - API versions, dependency quirks, reconnect edge cases found only in production - is what makes it a permanent line item. SFHooks is that line item, amortized: from $49/month, with the subscription lifecycle, delivery guarantees, and dashboards already built, soak-tested, and on our pager instead of yours. Your side of the integration is one HTTPS endpoint and four lines of verification code.
Frequently asked
How long does it take to build a Salesforce CDC consumer?
A happy-path Pub/Sub API subscriber takes an experienced engineer a week or two. Production-grade - replay persistence, silent-death detection, gap-event reconciliation, retry and dead-letter infrastructure, monitoring - is typically months, plus permanent maintenance.
What are the hardest parts of the Salesforce Pub/Sub API?
The failure modes that don't error: streams that must be opened and read in the same process or events silently vanish, idle connections that die without notice unless you ping, replay ids that expire after the ~72-hour buffer, and gap events that arrive with no field data and must be reconciled by re-fetching records.
When should I build instead of buying?
When compliance keeps third parties out of your data path, when you already run eventing infrastructure this can join, or when the integration is core product for you. Otherwise the subscriber is undifferentiated heavy lifting - the value is in what your code does with the events.