Change Data Capture for Salesforce API Integration: Real-Time Webhooks Without the Plumbing

If your product depends on knowing the moment something changes in your customer's Salesforce instance, you have probably already learned that polling is not a strategy. It is a tax. You pay it in API limits, in latency that frustrates users, and in engineering hours that get burned every time a Salesforce object schema shifts under your code. Change Data Capture for Salesforce API integration is the right answer, and it has been since Salesforce introduced the CDC channel in 2018. The problem is that consuming CDC events reliably, at scale, across thousands of customer tenants, is itself a substantial engineering project.

In our work with product teams building real-time CRM-aware features, this is one of the most common breakpoints we see. The team starts with a polling job that hits Salesforce every few minutes. It works in development. It works for the first few customers. Then a power user makes a thousand updates to leads in a five-minute window, the polling job misses half of them, and a sales manager loses trust in the dashboard your product is supposed to power. The team patches the polling. They tighten the interval. They hit Salesforce API rate limits. They start hearing about CDC and platform events. They look at the docs, they look at the queueing behavior, they look at replay IDs and gap detection, and they realize this is at least a quarter of engineering work that has nothing to do with their actual product.

This post breaks down what Change Data Capture for Salesforce really is, what makes it operationally hard, what real-time webhook delivery should look like when it is done right, and how Ampersand's Subscribe action turns the entire stack into a single declarative configuration.

What Change Data Capture for Salesforce Actually Does

Salesforce Change Data Capture is a streaming API that publishes events whenever records of subscribed objects are created, updated, deleted, or undeleted. The events flow over the Salesforce Streaming API on a CometD-based long-polling channel, with each event carrying a header that includes the change type, the affected record IDs, the changed field names, and a replay ID that lets a consumer pick up from where it left off after disconnects.

The key word in that paragraph is "streaming." CDC is not request-response. You do not call an endpoint and get a list of changes since a timestamp. You hold an open connection to Salesforce, you receive events as they are produced, you acknowledge them, and you persist the replay ID so you can recover from network failures. Salesforce retains CDC events for 72 hours, which sounds like a generous window until your consumer falls behind for a long weekend and you discover that gap detection is now your problem.

CDC supports standard objects (Account, Contact, Lead, Opportunity, Case, and dozens more) and custom objects. Each subscription is per object type, so a product that needs to respond to changes across the customer's full CRM data model maintains many subscriptions concurrently. Multiply that by every customer tenant your product supports, and the operational footprint grows quickly.

The data model of a CDC event itself is more useful than most teams realize at first glance. The header tells you not just that a record changed but which fields changed, which means a downstream consumer can decide whether to react at all without rehydrating the full record. The change types include CREATE, UPDATE, DELETE, UNDELETE, and a handful of bulk variants for operations affecting many records at once. Bulk events are particularly important because Salesforce will collapse a bulk update into a single CDC event referencing many record IDs, and a consumer that does not handle the bulk variants correctly will silently drop changes.

Why Polling Fails for Salesforce API Integration at Scale

Polling Salesforce is the path most product teams start on, and it works long enough to feel sustainable. The trouble surfaces in three predictable ways.

The first is rate limits. Salesforce enforces daily API call limits per org, and polling at any meaningful frequency consumes those limits aggressively. A product polling every customer's Salesforce every two minutes will burn through limits quickly, especially during peak business hours when the customer's own integrations are also hitting the API. Customers eventually notice that your product is the reason their nightly batch jobs are failing on rate limit errors, and they start asking you to back off. That conversation is not where you want to be.

The second is latency. Polling at five-minute intervals means events sit in your queue for an average of two and a half minutes before your product reacts. For a feature that promises real-time response, that latency is fatal. A sales rep who logs a call in Salesforce expects the next-best-action recommendation in your AI overlay to update immediately, not five minutes later when the rep has already moved on. We have written about how this latency problem compounds in agentic products in our piece on why conversational AI platforms need deep integration infrastructure to scale.

The third is correctness. Polling assumes that you can detect every change by comparing snapshots. In Salesforce, that assumption breaks in a few painful ways. Records can be updated and reverted within the polling interval, leaving no trace in your snapshot diff. Bulk operations affect more records than your pagination handles cleanly. Field history tracking is not enabled on every field, so even reaching into Salesforce's audit trail does not always tell you what changed. The result is a polling layer that quietly drops events, and the only way to find out is when a customer complaint forces you to look.

CDC fixes all three. Rate limits are not a factor because the streaming connection is its own quota class. Latency drops to seconds because events are pushed as soon as Salesforce processes the database commit. Correctness improves because you receive every event Salesforce emits, in order, with replay IDs to recover from disconnects.

The catch is that consuming CDC reliably is hard.

What Makes CDC Hard to Consume

The Salesforce CDC documentation makes the protocol look approachable. In practice, the operational complexity of running CDC consumers in production for a multi-tenant SaaS product is what gets engineering teams.

You need a long-running consumer process per Salesforce org. That process needs to maintain an authenticated CometD session, handle session expiration, refresh OAuth tokens, and reconnect cleanly without dropping events. You need to persist replay IDs durably so that if your consumer crashes and restarts, you do not replay the last 72 hours of events or, worse, miss events because you skipped the replay ID forward by mistake.

You need to handle the 72-hour retention window. If your consumer falls behind, you have to detect the gap, fall back to a query against the source object to recover state, and then reattach to the streaming channel at the correct replay ID. That recovery logic is where most homegrown CDC consumers break, because the fall-back query itself can hit rate limits, and the reattach race condition is subtle.

You need to handle subscription drift. If your customer enables or disables CDC for an object, or if a Salesforce admin changes object permissions, your consumer needs to react. If you launch a new product feature that needs to subscribe to a new object type, you need to roll that subscription out across every customer tenant safely.

You need to handle field mapping. The CDC event tells you the field API names that changed, but those names depend on the customer's specific Salesforce schema, which often includes custom fields. If your product expects certain fields and a customer renames them, you find out at runtime. We covered why this matters in detail in our piece on why your AI agent's memory is only as good as your field mapping strategy.

You need to handle multi-tenancy. A single shared consumer cannot handle every customer's CDC stream because Salesforce subscriptions are per org, authenticated per OAuth token. You need a runtime that scales consumer processes horizontally, isolates them per customer for blast radius reasons, and handles the lifecycle of consumers as customers churn or pause integrations.

And you need to deliver the events to your application. That means a transport layer (typically webhooks or a message queue), retry logic for failed deliveries, idempotency for replay scenarios, and an audit trail for compliance. By the time you have built all of this, you have written a streaming infrastructure project, not a feature.

Industry Context: Why Real-Time Salesforce Integration Became Table Stakes

The shift from batch to real-time CRM integration did not happen evenly. It happened in waves driven by specific product categories.

The first wave was conversational intelligence: products like Gong and Chorus that needed to know which calls connected to which Salesforce opportunities the moment the calendar event ended. These teams pioneered serious investment in CDC and platform events because their entire user experience depended on the join between their data and the CRM happening fast enough that a sales manager could pull up the call transcript in the opportunity record before the next meeting started.

The second wave was sales engagement and AI SDRs. Outreach, Apollo, and a generation of AI agent companies built their products around the assumption that a lead status change in Salesforce would immediately trigger a sequence change in their tool. Polling was never going to satisfy that assumption.

The third wave, which we are in now, is agentic CRM-aware AI. AI assistants embedded in CRMs, AI account researchers, AI deal coaches, and AI revenue intelligence layers all depend on knowing the state of the customer's CRM with sub-second latency. The customer expects the AI to know what just happened, and that expectation is non-negotiable. We wrote about how this wave breaks traditional integration patterns in how AI agents break every integration pattern that worked for traditional SaaS.

The pattern across all three waves is that the CRM is no longer a system the product reads from periodically. It is a system the product reacts to in real time. Polling is the architecture of the previous era. CDC is the architecture of the current one, and the products winning are the ones who treat real-time as a baseline requirement rather than a future enhancement.

The Ampersand Subscribe Action: CDC Salesforce API Integration as a Declarative Capability

Ampersand's Subscribe action is the abstraction layer that turns Salesforce CDC consumption into a configuration rather than a project. You declare in YAML which objects you want to subscribe to, which fields you care about, and where the events should be delivered. Ampersand handles everything else: the streaming connection, the replay ID persistence, the gap recovery, the rate-limited fallback queries, the per-tenant runtime, the field mapping, and the webhook delivery to your application.

Concretely, here is what changes for an engineering team that adopts Subscribe. You stop running long-lived CDC consumer processes. You stop maintaining replay ID stores. You stop writing reconnect logic. You stop building rate-limit-aware fallback queries. You stop worrying about whether a customer's schema change broke your subscription. Your application simply receives webhooks at the URL you configured, with structured payloads describing exactly what changed and which records were affected, in real time.

The Ampersand runtime publishes Subscribe events as they happen, typically within a second or two of the Salesforce database commit. Events are delivered with retries, idempotency keys, and signed payloads so your application can verify origin. Replay is supported, so if your service had downtime and missed events, you can request a replay window and the platform will redeliver. The same Subscribe abstraction works across Salesforce, HubSpot, Microsoft Dynamics 365, and other CRM systems where Ampersand has a streaming integration, which means your product gets one transport layer rather than one per CRM.

The 11x team described what this kind of infrastructure does to product latency: "Using Ampersand, we cut our AI phone agent's response time from 60 seconds to 5." That sixty-second-to-five-second improvement is exactly the gap between polling and real-time CDC, in the case of a product where real-time mattered. Engineering at Hatch, the Yelp company, framed it as a focus shift: "Ampersand lets our team focus on building product instead of maintaining integrations. We went from months of maintenance headaches to just not thinking about it." That maintenance burden is the CDC consumer, the replay store, the gap recovery, all the infrastructure Subscribe abstracts away.

For teams that want to see the architecture in product context, the Ampersand documentation covers the Subscribe action in detail, including event payload structure, delivery guarantees, and field mapping configuration. The how it works overview shows where Subscribe sits in the broader native product integrations stack.

Comparison: Approaches to Real-Time Salesforce API Integration

The pattern is consistent across this comparison. Latency improves as you move down the stack toward purpose-built streaming infrastructure. Engineering burden inverts: the closer to real-time you want to be, the more hidden complexity exists, and the more value there is in handing that complexity to a platform built for it.

The Ampersand Approach: Subscribe as One Capability in a Larger Stack

Subscribe is the answer to the real-time question for Salesforce, but it is one capability in a broader native product integrations platform. Most teams that need CDC also need bi-directional read and write to Salesforce, custom object support, dynamic field mapping, scheduled reads for non-real-time use cases, backfills when a customer first connects, and on-demand API endpoints for synchronous operations. Ampersand provides all of these as part of the same declarative framework, with shared authentication, logging, and dashboards.

That matters because real-time is rarely the only requirement. A typical product needs to react to CDC events in real time, but it also needs to read historical state, write back to Salesforce when the user takes an action, and handle the customer's custom objects and fields. Building one part of that stack on Subscribe and the others on a different vendor is the kind of architectural decision that creates technical debt fast. The teams we see succeeding are the ones who picked one platform for the entire integration surface and let the platform handle the variation across patterns.

For teams thinking about real-time integration in the context of AI products specifically, our piece on why CRM platforms need agent-ready integration infrastructure covers how Subscribe and the broader Ampersand stack support agentic workflows. For teams thinking about how real-time integration changes the build versus buy calculus, why AI automation platforms can't scale with in-house integrations walks through the economics.

FAQ: Change Data Capture Salesforce API Integration

Does Subscribe support all Salesforce objects, including custom objects?

Yes. Subscribe works against any object that Salesforce CDC supports, which covers standard objects and custom objects with CDC enabled. The configuration is declarative: you specify the object API name and the fields you care about, and Ampersand handles the subscription lifecycle. For objects where CDC is not available, Ampersand can fall back to platform events, change events on other channels, or scheduled query-based detection, depending on what fits the use case.

What happens if my application is down when a CDC event arrives?

Ampersand retries delivery with exponential backoff, configurable retry windows, and dead-letter queueing for events that fail repeatedly. Once your application comes back up, queued events are redelivered with their original ordering preserved per object instance. You can also request a replay of a time window if you need to recover from a longer outage, within the limits of Salesforce's CDC retention.

How does Subscribe handle Salesforce API rate limits?

Subscribe consumes events through the Salesforce Streaming API, which has its own quota class and does not consume the same daily REST API call limits that polling would. For the fallback query path used during gap recovery, Ampersand applies rate-aware throttling and respects per-org limits to avoid affecting your customer's other integrations.

Can I subscribe to specific fields rather than the entire object?

Yes. The Subscribe configuration lets you declare the fields you want included in the event payload, which both reduces the payload size and lets you scope the integration to exactly what your product needs. This is also a useful security posture: you avoid receiving fields you do not need, which simplifies your own data handling and audit scope.

How does Subscribe compare to building on Salesforce Pub/Sub API directly?

Salesforce Pub/Sub API is the gRPC-based successor to the CometD Streaming API and supports CDC, platform events, and other event types. It is more performant than the legacy Streaming API and is the right primitive to build on if you are constructing a CDC consumer from scratch. Subscribe abstracts whichever underlying transport Salesforce supports for the relevant event type, so your application code does not need to change as Salesforce evolves its event infrastructure. You get the latest transport with no migration work, which is exactly the value of putting integration runtime under managed infrastructure.

Does Subscribe work with Salesforce Sandboxes and Scratch Orgs?

Yes. The same configuration applies, and the runtime correctly handles Sandbox and Scratch Org authentication patterns. This matters for product teams that test integrations against customer sandboxes before production rollouts, which is a common pattern for any non-trivial change to integration behavior.

How is event ordering guaranteed?

Salesforce CDC guarantees ordering per record within an object stream. Ampersand preserves that ordering through its delivery layer to your webhook endpoint, with idempotency keys that let your application detect and handle the rare case of a retry causing a redelivery. Cross-object ordering is not guaranteed by Salesforce itself, so applications that need to correlate changes across objects should use the record IDs in event payloads to reconstruct the relevant relationships.

Conclusion: Real-Time Salesforce Integration Is a Solved Problem

Change Data Capture for Salesforce API integration is the right architecture for real-time CRM-aware features, and it has been for years. The reason most product teams have not adopted it is not that the value is unclear. It is that consuming CDC reliably across multi-tenant SaaS deployments is a streaming infrastructure project that no product team should have to take on as a side quest.

Ampersand's Subscribe action collapses that project into a configuration. Your engineering team writes a YAML block, your application starts receiving real-time webhooks, and the entire substrate of consumer processes, replay IDs, gap recovery, and rate limiting becomes infrastructure that someone else operates and audits. The latency wins are immediate, and the engineering hours you get back are the ones you should have been spending on your product all along.

If your product depends on knowing what just changed in your customer's Salesforce, the question is not whether to move from polling to CDC. It is how much engineering time you want to spend getting there. The teams who treat the integration runtime as their problem accumulate technical debt. The teams who treat it as infrastructure ship faster, hit better SLAs, and spend their engineering capital on what their customers actually pay them for. More on the broader pattern is at withampersand.com, and the Ampersand documentation covers Subscribe in technical depth for teams ready to dig in.