What SAP CDC actually sends downstream when consent changes
SAP CDC emits a real-time event the moment a customer changes a consent preference. Most integrations never read it. They read a nightly batch export instead, because that's what was easiest to build against three years ago and nobody has revisited it since. The gap between those two is where a withdrawn consent still gets a campaign.
The shape of the event vs. the shape of the batch
The event-driven path fires a webhook-style payload at the moment of change —
something shaped like { uid, consentIds: [...], isConsentGranted, timestamp } —
scoped to the one consent that changed. The batch export, by contrast, is a full
snapshot of the profile's current consent state, generated on a schedule and pushed
to whatever downstream system consumes it next.
The batch isn't wrong. It's just stale by construction: it reflects consent state as of whenever the export job last ran, not as of now. A customer who withdraws marketing consent at 9am is still "consented" in every system that only reads last night's export, until the next export runs — which, for a nightly job, is a full day later.
Why teams default to the batch anyway
- It was the simpler integration to build against the ESP's bulk-import API.
- It doesn't require the ESP to expose a webhook receiver or the team to run one.
- It "worked" in testing, because testing doesn't wait 18 hours between a consent change and the next campaign send.
None of these are wrong reasons to start with batch. They're wrong reasons to still be on batch once the flow is handling real consent withdrawals.
Batch vs. event-time propagation
| Batch export | Event-time propagation | |
|---|---|---|
| Latency | Up to one full sync cycle (often 24h) | Seconds |
| Audit trail | Snapshot only — no record of when it changed | Full event log, per consent, per timestamp |
| Build complexity | Low — bulk export/import | Higher — needs a webhook receiver and idempotent handling |
| Failure mode | Silent staleness | Missed events if the receiver is down without a replay mechanism |
Event-time propagation isn't free — it needs retry and replay handling so a receiver outage doesn't silently drop a withdrawal — but that's a known, solvable integration problem. Staleness-by-design isn't solvable without changing the architecture.
What to check first
If you're not sure which path your integration is on: find the job that writes consent state into your ESP, and check whether it's triggered by an event or by a schedule. If the answer is "cron," you have exactly the gap described above, whether or not it's caused an incident yet.
This is the Activate stage of the lifecycle: the resolved profile only carries real consent guarantees if the consent state travelling with it is current at the moment of send, not current as of last night's export.