Build on it
PlannedTell us when something changed.
Signed, idempotent deliveries for the events worth reacting to: a scan finished, a tracker appeared, an unknown technology was detected, a policy or manifest published, a health check failed, an integration errored.
Webhooks
- Scan & tracker events
- Policy & manifest events
- Health failures
- Signed, idempotent delivery
How it helps
What you get with Webhooks
Events about the site, not the visitor
Per-visitor consent does not fire a customer webhook by default — that would replicate visitor data into systems that should not hold it.
Signed and idempotent
Deliveries carry a signature and an idempotency key, so a retry does not create a second ticket.
Useful by default
The default set is chosen so a team can wire alerts without designing an event taxonomy first.
Developer & Platform
The rest of Developer & Platform
SDK, API, webhooks, CMS integrations and native website-builder support.
JavaScript SDK
Read the state, subscribe to changes, open preferences and gate your own code.
Learn moreREST API
Versioned endpoints for sites, scans, trackers, manifests, policies and integrations.
Learn moreWebsite Builders
Components declare their privacy impact; the Consent Manifest is generated at build time.
Learn moreCMS Integrations
WordPress, Shopify and Webflow over the same core API and runtime.
Learn moreAgency Management
Client organizations, reusable policies, roles, fleet reporting and site handover.
Learn moreKnow what runs before you ask visitors to trust it.
Start with a scan of what your website loads today. The list is usually longer than the team expects, and that is the useful part.
No code to install for a scan Public pages only DotCensus runs on DotCensus