Enterprise
Consent for a client list, not for one website
Most consent tools are priced and built for a single site, and running thirty of them means thirty logins, thirty invoices and thirty places a mistake can hide. This is the other shape.
Nothing is blocked, because nothing is there yet
Most platforms let the client's Google Analytics or Meta Pixel load and then try to stop it. We work the other way round. You take those tags off the site and give us the ID instead. It gets built into that domain's bundle and injected the first time a visitor says yes.
Until then the tracker is not in the page at all. No request, no cookie, nothing that needs blocking, and nothing that leaks while a blocking rule loses a race.
Pageviews are one pool, not thirty quotas
Every site you add puts another 30,000 pageviews a month into a single allowance for the account. 10 sites is 300,000, and it does not matter how that splits between them.
A client having a launch month draws from the same pool as one that is quiet, so you are not topping up one site while another sits half used. You buy headroom for the portfolio once.
One command in, and the same care on the way out
npx consentify-migrate finds the consent tool a site already runs, removes it, and installs Consentify with the categories mapped across. Minutes per site rather than an afternoon.
If you ever want to leave, we help with that too: your consent records export, your integration IDs come back, and there is no annual contract to run out first. Holding an agency's client list hostage is not a business we want to be in.
Under the hood
One page load, line by line
Open the network panel on any site running Consentify and follow along. Every step below leaves a trace you can see yourself, which is a better argument than a list of adjectives.
- 01
GET /api/gateway?token=pk_live_...
200 · max-age=86400
One request, cached for a day
The banner arrives as a single file from the edge, so there is no round trip to an origin server before it can appear. The client tag ids are already inside it, baked in when the config was saved. In our database those ids sit encrypted with AES-256-GCM and are decrypted in memory only, while the file is built.
- 02
(no third-party requests)
waiting
Nothing to block, because nothing has loaded
Until the visitor accepts, the vendor tag is not on the page at all. There is no request to cancel and no cookie to clean up afterwards. Everything in the panel at this point belongs to the site itself.
- 03
#csfy-root :: #shadow-root (open)
mounted
The banner mounts in its own root
It renders inside an open shadow root. It inherits nothing from the site CSS and puts nothing into the global scope, which is what lets one setup survive thirty different themes without a single override per site.
- 04
POST /api/gateway/save
200 · on accept
Accepting is the moment anything happens
The allowed tags are injected, and the decision is written down: which categories were accepted, which were rejected, the policy version, and a hash of the IP. The raw address is never stored, so there is nothing sensitive to leak later.
- 05
csfy_consent
localStorage + cookie, 1 year
The record belongs to the visitor too
The choice is kept locally for a year, and the response carries a delete token. That token is what /api/gateway/delete needs, so a data subject request is answered by the visitor pressing a button rather than by someone querying a database.
Ready to talk?
Tell us about your setup, domains, stack, compliance requirements and we'll put together a custom proposal within one business day.