Guide · June 17, 2026
CMP integration with APIs/webhooks: capture consent, sync backend, log
Guide to integrate a CMP via APIs/webhooks to fetch consent, sync backend, and log under the PDPL for Vietnamese businesses.
Quick answer
What is CMP API/webhook consent integration?
CMP API/webhook consent integration connects your cookie/consent management tool with your backend, CRM, CDP, or data warehouse to receive consent status in real time. For Vietnamese businesses, the goal is not just to “show a banner” but also to store evidence of consent, synchronize with the systems that process personal data, and retrieve it when there is a DSAR or an internal audit.
In practice, a CMP typically generates three data groups: current consent status, change history, and metadata such as timestamp, policy version, and processing purposes. When integrated correctly, your backend will know which users are permitted to enable analytics, marketing, or third‑party sharing under the regulations.
Which consent statuses should you pull into the backend?
You should synchronize at least the statuses that matter operationally, not just a generic single “consent” flag.
- Consent by purpose: necessary, analytics, marketing, personalization.
- Consent by processing source: web, app, kiosk, lead form, call center.
- The version of the notice/terms the user saw.
- The time of capture, IP/device if your policy and regulations allow storing it.
- Consent withdrawal status and the time of withdrawal.
For SMEs, if you only use a CMP for the website but the data flows into email automation, ads, and customer support, you should map consent into clear internal states, for example marketing_allowed=true/false, analytics_allowed=true/false. This makes it much easier for developers and operations teams to control.
Should you use API or webhook when integrating a CMP?
You should use both if your system is large enough: API to query the current status, webhook to receive changes as soon as consent is updated.
| Approach | When to use | Advantages | Limitations | |
|---|---|---|---|---|
| API | Backend needs to check consent at processing time | Proactive queries, easy reconciliation | May be slow if called continuously | |
| Webhook | Need to sync as soon as the user changes their choice | Near real time, reduces polling | Must handle retry, idempotency, security | |
| Both | Systems with many services and many data sources | Both near real time and verifiable | Requires more careful design |
A common pattern is: the webhook updates consent into a central database, while the API is called during page rendering, when running a marketing job, or before sending data to a third party. This reduces drift between the CMP and internal systems.
How do you integrate CMP API/webhook consent into the backend?
Practically, you design a “consent store” in the backend, and have other services read from it instead of querying the CMP every time.
Define processing purposes:
List the cookies/processing purposes that require consent: analytics, ads, remarketing, profiling, data sharing.
Standardize a consent schema:
Create a table or document with fields such as `user_id`, `anonymous_id`, `purpose`, `status`, `source`, `version`, `timestamp`.
Receive webhooks from the CMP:
When the user changes their choice, your endpoint receives the event, verifies the signature, then writes it to the consent store.
Synchronize with business backends:
Update the CRM/CDP/email tool so subsequent jobs only run on users who meet the criteria.
Log and store evidence:
Store the request id, a minimized payload, the receipt time, and the banner/policy version for later retrieval.
Design retry and idempotency:
If a webhook is delivered twice, the system must detect it and avoid overwriting the status incorrectly.
Periodic checks:
Reconcile the CMP with the backend to detect data drift, mapping errors, or expired tokens.
Example: an e‑commerce marketplace in Vietnam enables remarketing ads on Meta and Google. When a user declines marketing consent on the banner, the CMP webhook updates marketing_allowed=false. The CRM backend must stop adding that person to audience sync, while the logging system still keeps traces to demonstrate compliance.
What should you log to demonstrate compliance?
You should log enough to prove “who consented to what, when, and how,” but avoid turning logs into a warehouse of unnecessary data.
Recommended to store:
- A user identifier or a pseudonymous ID.
- Consent purposes and status.
- Timestamp and the version of the notice content.
- Source of the event: website/app/API.
- Webhook event code, request id, processing result.
- A trace of consent withdrawal if any.
Do not indiscriminately store unnecessary sensitive content in application logs. If you must keep it for audit, restrict access, encrypt it, and set a retention period that matches internal policy. Under personal data protection rules, logging is also a data processing activity and must have a legal basis and a clear purpose.
What PDPL compliance notes apply when using a CMP with API/webhook?
The Personal Data Protection Law (Law 91/2025/QH15) is expected to take effect on 01/01/2026, replacing Decree 13/2023/ND-CP. When implementing a CMP integration, businesses should prepare early because the enforcement authority is the Ministry of Public Security — Department of Cybersecurity and High-tech Crime Prevention (A05).
Key points to remember:
- If an API/webhook exposes data, you must have processes to detect and handle incidents.
- When a data breach is detected, notify within 72 hours from discovery as required.
- Specific penalty levels will be set by the Government’s implementing decree; figures are not fixed at this stage.
- Serious violations may lead to criminal liability.
With CMPs, the most common risk is not “no banner,” but incorrect synchronization of consent between the front end and the backend, causing marketing jobs to run even after the user has declined. That is an operational error, but it can trigger legal risk if data continues to be processed.
What webhook payload and log samples should you use?
If you’re on the engineering team, a minimal payload could look like this:
{
"event_id": "evt_123456",
"user_key": "anon_abc999",
"source": "web",
"policy_version": "2026-01",
"consents": {
"necessary": true,
"analytics": false,
"marketing": true
},
"updated_at": "2026-02-15T10:20:30Z"
}
Internal logs should add processing status:
event_id=evt_123456
received_at=2026-02-15T10:20:31Z
signature_valid=true
stored=true
backend_sync=success
crm_sync=skipped_reason=no_marketing_consent
This template is sufficient for developers to implement, while legal/compliance still has data for reconciliation. If your system has many services, create a central consent service instead of stuffing consent logic into each individual microservice.
- Yes, if your system processes data across multiple services. Storing it in the backend helps synchronize, re‑check, and prove the consent status when needed.
- Not exactly. Webhooks are suited for receiving changes immediately, while APIs are useful when the backend needs to re‑check the current status before processing data.
- Update the status immediately in the consent store, block subsequent jobs that use that data, and synchronize the change to the CRM/CDP/ad platforms if any.
- They should not be retained indefinitely. Set a retention policy appropriate to the purpose, risk, and internal rules; when needed, consult a lawyer or compliance specialist.
If you are standardizing banners, storing evidence of consent, and DSAR on consent.vn, design the API/webhook flows so that developers and compliance share a single source of truth.
Source: the Personal Data Protection Law (Law 91/2025/QH15), Decree 13/2023/ND-CP: https://thuvienphapluat.vn ; Enforcement authority A05: https://bocongan.gov.vn
Get started — set up in 5 minutes.
Deploy PDPL solutions for your business?