How it works
Who talks to whom, from setting up a notice to proving a consent and answering a rights request.
PIEDAP Consent sits between your website or app and your team. A small script on your pages asks visitors and holds back tags. The service records every answer as evidence. Your team manages it all from the console. Your servers read, record and act on consent through the API and webhooks.
The flow, step by step#
-
Your team → PIEDAP Consent
Set up and publish
In the console you list your purposes, write the notice, choose where it applies and publish it. Every published version is kept.
-
Visitor → Your site
A visitor opens a page
The runtime, one script tag at the top of the page, starts before anything else. It holds back the tags you marked and the third-party tags it recognises.
-
Your site → PIEDAP Consent
The right form is chosen
The runtime asks which form applies to this visitor's place and language, and whether they have already answered the current version.
-
Your site → Visitor
The notice is shown
The visitor sees each purpose, the data it uses and their rights, in their language. They accept, refuse or choose purpose by purpose.
-
Your site → PIEDAP Consent
The answer is recorded and sealed
The choice is stored with the exact wording shown, and sealed so that a later change would show. The visitor's identifier is kept only as a hash that cannot be turned back into it, unless you choose otherwise.
-
Your site
Allowed tags run
Tags for the purposes and partners the visitor allowed now run. The rest stay blocked. The choice is remembered for next time.
-
PIEDAP Consent → Your servers
Your systems are told
A webhook, a signed message to your server, reports each grant, change, withdrawal, expiry, erasure and rights request. Your customer database and marketing tools stay in step.
-
Your servers → PIEDAP Consent
Your servers ask and act
With a secret key your servers record consent taken at sign-up, check what a person agreed to, and find, export, withdraw or erase everything held for them.
-
Visitor → PIEDAP Consent
People use their rights
From the privacy button or a link you send, people review and withdraw their consents, or file an access, correction or erasure request on a hosted page.
-
Your team → PIEDAP Consent
Your team answers and proves
In the console your team looks up a person's records, fulfils requests before their deadline and exports a signed receipt when someone asks for proof.
What runs where#
| Part | Where it runs | What it does | Read more |
|---|---|---|---|
| Runtime | The visitor's browser, on your pages | Shows the notice, holds back tags, remembers the choice | Install on a website |
| Mobile SDKs | Your iOS and Android apps | Fetch the form for your own consent screen, record the answer, read choices | Record consent in a mobile app |
| Service and API | The deployment at https://console.dpconsent.com/consent | Chooses the form, records and seals answers, sends webhooks | API reference |
| Console | Your team's browser | Purposes, forms, languages, regions, keys, records, requests | Set up your first banner |
| Server SDKs | Your servers | Record consent, look people up, verify webhooks and receipts | Node.js client, Python client |
| Hosted pages | The deployment, opened by your visitors | Privacy notice, rights request page, consent portal, unsubscribe | Link to the hosted pages |
What stays with you#
The product records and proves consent. It does not send email, SMS or WhatsApp messages for you. It does not delete data in your own systems: a webhook tells you when to. The DPDP reference, starting with DPDP duties for notice and consent, lists duty by duty what the product does and what stays with you.
Related#
- Key ideas: the words used across the console and API.
- Set up your first banner in the console.
- Put a banner on a test page: the quickstart for developers.