Consent Management APIs: How to Sync Consent Across Applications

A customer turns off marketing consent in your mobile app.

Your app records the withdrawal. Your CRM still says opted_in, and your email platform still has a campaign scheduled for that customer.

The customer has already said no. Two of your systems still think the answer is yes.

A Consent Management API keeps that decision from getting trapped inside one application. The mobile app sends the withdrawal to a central consent record. The CRM receives the new status. The email platform gets the same update and stops using the old permission.

So how do you keep consent in sync across several applications without losing changes along the way?

In this guide, I’ll explain how consent APIs work, how consent changes move between applications, and how to handle withdrawals without leaving old permissions active in another system.

What Is a Consent Management API?

A Consent Management API lets applications work with the same consent record instead of keeping separate answers for the same person. Let’s say a customer agrees to receive marketing emails in your mobile app. The consent record can store the customer ID, email_marketing as the purpose, granted as the status, when the choice was made, and the app as the source. 

Your CRM can read that record before marking the customer as opted in. If the customer later turns marketing off, the consent status changes to withdrawn. Systems using that permission can then receive the new status rather than continue using the earlier granted record.

This prevents one application from treating consent as active after the customer has already withdrawn it somewhere else.

Why Consent Synchronization Across Applications Is Needed

Consent does not stay fixed. People can grant it, change what they agreed to, or withdraw it later. Every system relying on that decision needs to work from the current status. Consent synchronization is needed because:

• A consent change made in one application can reach the other applications using it.
• A withdrawal can replace an older opted_in status before that permission is used again.
• Your CRM and marketing tools can work with the same consent status instead of storing different answers.
• Your team does not have to update the same consent choice manually across several systems.
• Each grant, change, and withdrawal can be recorded with its time, source, and purpose.
• You can trace which consent was active if the customer’s decision is questioned later.

The biggest concern is withdrawal. Recording withdrawn in one place means little if another application continues acting on the previous granted status.

How Do Consent Management APIs Work?

Let’s say a customer changes email_marketing from granted to withdrawn in your mobile app. The app can send that change to the consent system through an API request. The request identifies the customer, the purpose being changed, and the new consent status.

The consent system records the new decision. Consent records can also include details such as when the choice was made and where it was collected. OneTrust, for example, supports consent transactions tied to data subjects and individual purposes.

Once the status changes, connected applications need the new value. There are two common ways this happens.

• An application requests the customer's current consent status through an API before using that permission.
• A webhook sends an HTTP POST when the consent changes. Didomi documents this approach for consent changes made through websites, mobile apps, and preference centers.

The update may not appear everywhere instantly. If the CRM receives email_marketing: withdrawn, it still has to apply that status to the customer. The email platform must also stop relying on the previous opt-in. Receiving the withdrawal and enforcing it are separate steps.

The consent record remains available after the change. That gives you a history of what the customer selected, when the decision changed, and which purpose the decision applied to.

How to Sync Consent Across Multiple Applications

Suppose a financial services company collects consent through its website and mobile banking app. Its CRM holds customer records, while an email platform sends marketing campaigns. Here is how consent can stay in sync across those applications.

1. Identify Every Application That Uses the Consent

First, the company needs to know where marketing consent enters the system and where it is used.

In this example, the website and mobile app collect the customer's choice. The CRM stores the customer's marketing status. The email platform uses that status before sending promotions. Any third-party processor using the same consent also belongs on this list.

2. Create a Central Consent Record

The customer's choice needs one record that the connected applications can refer to. Depending on the consent system, a marketing consent record may contain:

• User ID customer_18452
• Purpose email_marketing
• Status granted
• Timestamp 2026-11-02T09:30:00Z
• Source mobile_app
• Notice version marketing_v4

If the customer later withdraws marketing consent, that purpose changes to withdrawn. Other consent purposes do not need to change with it.

3. Connect Each Application Through the API

The website and banking app need a way to submit consent choices. The CRM and other systems may need to retrieve the current choice.

So when customer_18452 changes email_marketing, the banking app sends the new status against that customer and purpose.

API authentication and access controls depend on the consent platform. Where separate permissions are available, an application that only needs to read consent does not necessarily need permission to change it.

4. Send the Change to the CRM and Email Platform

The new status should not sit in the central record waiting for every application to check it. A webhook or event notification can tell the CRM and email platform that email_marketing has changed for customer_18452. Another option is for an application to request the latest consent status through the API.

The event needs to identify the customer, purpose, new status, and time of the change so the receiving system knows exactly what changed.

5. Make Sure withdrawn Actually Stops Marketing

This is the part that matters most.

The CRM needs to replace the previous marketing status. If the email platform's promotional messages rely on that consent, it needs to stop using the old permission and prevent the customer from receiving later promotional messages.

If the email platform does not receive the update, the withdrawal is not fully applied across the connected systems. Your integration may need to record the failed delivery and retry it instead of leaving granted active there.

6. Record What Happened to the Withdrawal

The consent record should show that customer_18452 withdrew email_marketing, along with the time and source of that decision.

Your integration logs can separately show what happened after that:

• The CRM received the withdrawal.
• The email platform received the withdrawal.
• A failed delivery was retried.
• The receiving system processed the new status.

Now, if the customer receives another marketing email, you can trace the withdrawal from the original choice to the system that failed to apply it.

Consent Management API Example

Let’s use customer_18452 from our earlier example. They have just turned off email marketing in the mobile app. The examples below are illustrative. The exact endpoint, fields, and authentication will depend on the consent platform.

1. The App Submits the Withdrawal

The mobile app could send a request like this:

PATCH /v1/consents/customer_18452

Authorization: Bearer <token>

Content-Type: application/json

{

  "purpose": "email_marketing",

  "status": "withdrawn",

  "source": "mobile_app",

  "timestamp": "2026-11-02T10:15:00Z"

}

Notice that the request does not simply say the customer withdrew consent. It identifies which consent changed and where that decision came from.

2. The API Confirms What Was Recorded

If the request is accepted, a response could look like this:

{

  "consent_id": "consent_67291",

  "user_id": "customer_18452",

  "purpose": "email_marketing",

  "status": "withdrawn",

  "updated_at": "2026-11-02T10:15:00Z"

}

Now there is a specific consent record tied to that withdrawal.

3. Other Systems Receive the Event

Next comes the part that connects the change to other applications. A webhook could carry an event like this:

{

  "event_id": "evt_92841",

  "event": "consent.withdrawn",

  "consent_id": "consent_67291",

  "user_id": "customer_18452",

  "purpose": "email_marketing",

  "status": "withdrawn",

  "occurred_at": "2026-11-02T10:15:00Z"

}

The event_id is useful here because the receiving application can recognize the event if the same webhook is delivered again. The API response tells you the withdrawal was recorded. The webhook tells another application the withdrawal happened. You still need confirmation from that application if you want to know that it actually processed the change.

Consent API Requirements Under GDPR and DPDPA

GDPR and DPDPA do not require a consent API. They set rules for how consent is collected, recorded, and withdrawn. If you use an API to manage consent, it needs to support those rules.

Under GDPR Article 7, you must be able to show that consent was given. A person can also withdraw it at any time, and withdrawing must be as easy as giving consent.

Under Section 6 of India's DPDPA, consent must be free, specific, informed, unconditional, and unambiguous. The person must also be able to withdraw consent with ease comparable to giving it.

There is one timing detail to know. The main DPDPA provisions covering consent are scheduled to take effect 18 months after November 13, 2025, which is May 13, 2027.

Common Challenges in Consent API Integration

Even if the API connection works, consent can still get out of sync between applications. A few problems need extra attention:

• User identity mismatch can link a consent change to the wrong record or leave it unmatched.
• Delayed updates can leave an older consent status active in another application for longer than expected.
• Failed API or webhook calls can prevent a consent change from reaching another system.
• Duplicate events can cause the same consent change to be processed more than once.
• Events arriving out of order can cause an older consent status to overwrite a newer one.
• Missing audit records can make it hard to prove where a consent change was sent and whether it was processed.

These problems become harder to manage as more applications start using the same consent data. A consent management platform such as ConsentIQ can give those applications one place to work from. Next, let’s see how ConsentIQ handles this. 

How ConsentIQ Supports Consent API Integrations

If you are building consent into your own application, ConsentIQ by IQWorks provides a REST API for custom integrations.

Consent collected through the API goes into its central consent store. Each purpose can have its own consent record.

From there, ConsentIQ can handle the consent data in a few ways:

• REST API collects consent from custom applications.
• Purpose-level records keep permissions separate.
• CRM consent sync writes decisions to supported CRMs.
• Consent changes update the person's stored status.
• Tamper-evident records keep a history of consent choices and later changes.

So in our earlier example, the banking app could use the API to record the customer's marketing choice. If that customer later withdraws consent, the new status can be recorded against the same purpose. 

ConsentIQ also supports one-way consent sync with HubSpot, Salesforce, Zoho CRM, Microsoft Dynamics 365, Adobe Marketo Engage, and LeadSquared.

The sync is data-blind. ConsentIQ matches contacts using a hashed email or phone number. Personal data stays inside the CRM. Only the consent decision is written back. 

Conclusion

A consent API should leave no doubt about which permission is current.

When someone changes or withdraws consent, the new status should be recorded against the right person and purpose. Systems using that consent should stop relying on the old status. If an update fails, you need a record of that failure so it can be fixed.

This is the part you should get right before connecting more applications to the same consent data.

ConsentIQ provides a REST API for adding consent management to your own application. You can use it to record purpose-specific consent and later changes without building the consent system yourself.

If you need consent built into your product through an API, connect your application with ConsentIQ.

Frequently Asked Questions

1. What is a Consent Management API?

A Consent Management API lets applications record, retrieve, or update consent data. The exact functions depend on the API. Consent can be stored against a specific person and purpose, such as email_marketing.

2. What happens when a user withdraws consent through an API?

The consent record should be updated to show that the relevant permission has been withdrawn. Systems relying on that consent also need the new status so they stop using the previous permission.

3. Should consent be stored separately for each purpose?

Yes, if you are relying on consent for different purposes. A person may agree to one purpose and refuse another. GDPR requires consent to be specific. India's DPDPA also requires consent to be specific and limited to the personal data necessary for the stated purpose.

4. Can webhooks be used with a Consent Management API?

Yes. Some consent platforms support webhooks that send an event when consent changes. This can reduce the need for another application to keep checking the API. Webhook support and event formats depend on the platform.

5. How do you prevent duplicate consent events from being processed?

A receiving system can use a unique event or transaction identifier to recognize an event it has already processed. The exact method depends on how the API and webhook integration are designed.