A customer withdraws marketing consent at 10:14 in the morning.
The consent system saves the change. CRM receives it and updates the customer record. Somewhere on the way back, however, the acknowledgement disappears.
Thirty seconds later, the sender tries again.
The customer has made one decision. Yet a poorly designed consent history can now show two withdrawals simply because the same message travelled twice.
That may sound like a small technical oddity. It becomes much more serious when Privacy, Compliance or Legal later relies on that history to understand what the person actually did.
This is one of the less visible challenges in user consent management. Recording the choice is only part of the job. A consent management system also needs a dependable way to recognise the same choice when APIs, webhooks or queues deliver it more than once.
One simple design element helps enormously: a stable event ID.
Why the Same Consent Event May Arrive More Than Once
Most people do not experience consent as a technical workflow.
They tick a box, change a preference or withdraw permission. From their point of view, the action happens once.
Behind the screen, that decision may need to travel through several systems.
A preference centre records it. A consent service stores it. CRM needs the new state. A marketing platform may need to stop using the permission. An internal data service may need the same update.
These systems do not always communicate perfectly.
A network connection may drop after the receiving application has already completed the work. A webhook can time out before it receives a success response. A queue may replay a message after an outage.
Retrying the delivery is usually sensible. It is how distributed systems recover from temporary failures.
The difficulty is knowing whether the second message represents:
a second decision from the customer, or simply another attempt to deliver the first one.
Those are completely different things from a consent-history perspective.
Think of an Event ID as the Reference Number on a Transaction
There is an easy way to understand the role of an event ID without thinking like a software engineer.
Imagine making a bank transfer.
The confirmation may appear on your phone, in an email and later on a statement. Those are several records or notifications connected to the same underlying transaction.
You would not want each notification treated as another payment.
A consent event ID serves a similar purpose.
When a customer withdraws marketing consent, the system creates a unique reference for that specific lifecycle event:
evt-9031
If delivery fails and the same event has to be sent again, it keeps the same identity.
The receiving system can then recognise:
We have already processed evt-9031.
It can acknowledge the retry without adding another withdrawal to the customer's consent history.
This is not a proprietary consent-management idea. The CloudEvents specification maintained by the Cloud Native Computing Foundation uses an event id for much the same reason. Its specification says that a recent duplicate may retain the same ID and that consumers may use matching source-and-ID values to recognise duplicates.
Why a Timestamp Cannot Do the Same Job Reliably
Consent histories obviously need timestamps.
They help establish when a person gave, changed or withdrew a permission.
The problem comes when the timestamp is also expected to identify the event.
Consider the withdrawal at 10:14.
The original consent service may record:
10:14:22.481
CRM receives the message a fraction of a second later.
A retry arrives thirty seconds afterwards.
Another downstream service might store time only to the nearest second. A different system may record when it received the event rather than when the customer actually acted.
Suddenly one decision has several times associated with it.
Trying to decide whether two records are duplicates because their timestamps are “close enough” quickly becomes unreliable. A customer might genuinely make two changes within a short period. Different systems can use different levels of precision. Delayed messages may also arrive out of order.
The timestamp remains important because it explains when the action occurred.
The event ID provides a separate reference for which action the record represents.
Keeping those responsibilities separate makes the consent history much easier to trust.
What the Record Needs to Carry
A consent event does not need an enormous payload to be useful.
For a marketing withdrawal, the meaningful information might look conceptually like this:
{
"event_id": "evt-9031",
"user": "customer-84721",
"purpose": "marketing",
"previous_state": "granted",
"new_state": "withdrawn",
"occurred_at": "2026-09-09T10:14:22Z",
"source": "preference-centre"
}
The important point is not the exact field names. Every architecture will make different choices.
The value comes from having enough information to distinguish the person, the purpose, the state change, the time of the action and the identity of that particular event.
Delivery information can be stored separately.
The first webhook attempt might be delivery 1. The retry might be delivery 2. Operations can retain both because those attempts are useful when diagnosing an integration problem.
Privacy does not need two consent withdrawals simply because Operations has two delivery attempts.
That separation keeps both histories useful.
What Actually Goes Wrong Without It
Imagine the same customer withdrawal reaching CRM.
CRM applies the update correctly. Marketing consent is now withdrawn.
Its response is lost, so the consent service tries again.
If CRM simply processes every incoming message as a new event, the customer history may end up looking like this:
10:14 — Marketing consent withdrawn 10:15 — Marketing consent withdrawn
Nothing obviously breaks.
Marketing remains withdrawn either way.
That is partly why this type of problem can survive unnoticed.
The damage is in the meaning of the record.
A reviewer looking at the history later may assume the customer interacted with the preference centre twice. Analytics may count two withdrawals. An audit export may contain events that never happened at the user level.
The underlying state can be correct while the history is still wrong.
For consent systems, that distinction matters.
Event IDs Help, but the Receiving System Still Has Work to Do
Adding an ID to the message is only the first step.
The receiving application has to do something useful with it.
When evt-9031 arrives for the first time, the consumer records that the event has been processed and applies the consent change.
When the same evt-9031 appears again, it recognises the identifier and does not repeat the underlying action.
This behaviour is usually described as idempotency. In plain English, it means the same logical request can be repeated without creating additional unintended effects.
AWS discusses this problem extensively in its guidance on making retries safe with idempotent APIs. The engineering challenge described there is familiar: a caller may not know whether an operation succeeded before a timeout, so a retry should not accidentally perform the same side effect again.
GitHub's own webhook guidance provides another practical example. Its webhook best-practice documentation recommends using a delivery identifier, and GitHub keeps the same delivery header when an event is deliberately redelivered.
Consent technology has its own domain rules, but the reliability principle is familiar across modern software systems.
A Retry and a New User Choice Should Look Different
There is another reason not to rely only on timestamps or message contents.
A user can genuinely make another decision.
Suppose the customer withdraws marketing consent at 10:14 and later changes their mind and grants it again at 10:20.
Those are two real lifecycle events.
They should have two event IDs.
The withdrawal might be:
evt-9031
The later grant:
evt-9032
A second delivery of evt-9031, however, remains the same withdrawal.
This makes consent histories easier to reason about because the model reflects what happened in the real world:
one user action = one logical consent event
The transport system may attempt to deliver that event several times without creating several user actions.
Event Identity Is Also Different From Event Order
An ID helps a system recognise a duplicate. It does not automatically tell the system which of two genuine events happened first.
This matters when different updates are travelling at the same time.
Imagine a customer withdraws consent and then grants it again shortly afterwards. A delayed message could cause the earlier withdrawal to reach one application after the newer grant.
The system may therefore need a version number, sequence or other ordering mechanism alongside the event ID.
That sounds technical, but the business consequence is simple.
The organisation needs to avoid two different mistakes:
recording the same choice twice;
applying genuine choices in the wrong order.
An event ID addresses the first problem. Ordering logic addresses the second.
Keeping those concerns separate produces a cleaner lifecycle architecture.
Why Privacy Teams Should Care About This Engineering Detail
Most Privacy teams will never configure an event broker or write idempotency code.
They still depend on the result.
Consent evidence is useful only when it represents the person's real actions accurately.
India's Digital Personal Data Protection Act, 2023 contains specific requirements around consent, including circumstances in which a Data Fiduciary must be able to prove that notice was given and consent was obtained in accordance with the Act and Rules. Those substantive provisions are subject to the phased commencement schedule established in November 2025.
The Act does not require UUIDs, event IDs or webhook architecture.
Those are engineering choices.
But once an organisation chooses to maintain consent evidence electronically, its technical design affects how accurately that evidence reflects the underlying lifecycle.
A history containing two withdrawals because one webhook retried is not more complete. It is more confusing.
Consent Lifecycle Management Becomes Harder Across Channels
This issue grows as consent leaves the preference centre.
Modern consent lifecycle management can involve websites, mobile apps, CRM, marketing platforms, APIs and other systems that depend on the same user choice.
Every new handoff creates another place where a delivery can fail and be retried.
That makes event identity especially relevant to organisations evaluating a consent lifecycle management solution. Visible features such as preference capture, withdrawal and dashboards are important, but the integrity of the lifecycle underneath them matters too.
AquaConsento describes its consent lifecycle controls around purpose-level consent states, version history and downstream propagation across web, app, API and offline journeys. In this kind of multi-system consent management system, preserving a reliable lifecycle means keeping the person's actual consent event distinct from the technical attempts used to move that event between applications.
This is the only AquaConsento link the article needs. The engineering principle stands on its own regardless of platform choice.
A Simple Test Can Reveal the Problem
Teams do not need a complicated resilience programme to check whether duplicate deliveries are polluting consent history.
Take one consent change in a controlled test environment and allow the receiving application to process it normally.
Then replay the same event using the same event ID.
The operational logs may quite reasonably show two deliveries. The user's consent history should still contain one lifecycle event.
If another withdrawal appears each time the message is replayed, the system is treating delivery attempts as user decisions.
That is the bug worth fixing.
The same exercise can also reveal a second problem: some systems recognise the duplicate but still repeat related side effects, such as notifications or downstream updates. Those actions need the same idempotency thinking.
FAQ
What is an event ID in user consent management? ↓
Is a timestamp enough to identify a consent event? ↓
Does the DPDP Act require event IDs? ↓
One Choice Should Still Look Like One Choice
Retries are normal.
A webhook can time out. A queue can replay a message. A downstream system can receive the same consent event more than once.
None of those things means the customer made another decision.
That is the line a reliable consent architecture needs to preserve.
Operational teams should be able to see every delivery attempt because those details help them diagnose failures. Privacy and Compliance should see the lifecycle as the user actually experienced it.
One withdrawal should remain one withdrawal.
A stable event ID will not solve every consent-management problem, but it prevents a surprisingly important one: allowing the mechanics of software delivery to rewrite the history of what a person chose.