UMAP360 enforces consent for device fingerprinting server-side, on a fail-closed basis aligned with India's DPDP Act and the GDPR. This guide covers what's enforced today and how to signal consent on the events you send.

The fingerprint-consent gate

A device fingerprint is a powerful identity signal, so it's the field UMAP360 gates. If you send context.fingerprint, the server keeps it only when the same event carries an explicit consent grant. Otherwise the fingerprint is stripped before identity resolution and never stored — it cannot stitch identities or land in the event row.

The server treats any of these as a grant:

• context.consent === true — a blanket grant, or
• context.consent.fingerprinting === true, or
• context.consent.identity === true.

Anything else — consent absent, false, or malformed — fails closed (the fingerprint is stripped). The client value is advisory; the server is the authority.

{
  "type": "page",
  "messageId": "msg_3001",
  "timestamp": "2026-06-08T10:00:00.000Z",
  "anonymousId": "anon_xyz789",
  "context": {
    "consent": { "fingerprinting": true, "analytics": true },
    "fingerprint": { "hash": "fp_abc123" }
  }
}

What is and isn't gated

• Gated server-side: the device fingerprint, as described above.
• Not gated by this mechanism: ordinary event data (track/page/screen events, properties, traits, campaign context) is ingested as sent. Collecting valid consent before you send analytics or marketing data is the integrator's responsibility — UMAP360 stores what you send it.

Respecting browser-level signals such as Do-Not-Track or Global Privacy Control is a decision for your client or SDK to make before it sends an event; the REST endpoint acts on the consent object you provide, not on browser headers.

With the Web SDK

If you use the Web SDK, it records consent for you (POSTing to /v1-consent) and emits context.consent on every event:

umap360.consent.grant('analytics');      // or .deny('analytics')
umap360.consent.grant('fingerprinting'); // gates the device fingerprint
if (umap360.consent.hasConsent('analytics')) {
  umap360.track('Signed Up');
}

Don't track until consent. With the defaults (trackPages: true), the SDK sends the first pageview as soon as init() runs — before a banner is answered. To hold all tracking until the visitor opts in, start with capture off and turn it on when they accept:

// 1. Initialise without auto-tracking, then hold all capture.
umap360.init({
  writeKey: 'uk_live_…',
  apiHost: 'https://YOUR_PROJECT_REF.supabase.co/functions/v1',
  trackPages: false,
});
umap360.setEnabled(false); // nothing is captured until you re-enable

// 2. Show your banner. On "Accept":
umap360.consent.grant('analytics'); // recorded to /v1-consent
umap360.setEnabled(true);           // resume capture
umap360.page();                     // fire the first pageview now

// On "Reject":
umap360.consent.deny('analytics');  // recorded; capture stays off

consentMode: 'enforced' also makes deny('analytics') stop capture, but a brand-new visitor still starts enabled until they choose — so the explicit setEnabled(false) above is the reliable "off by default" switch. A Do-Not-Track / GPC opt-out is honoured at init() and is not lifted by a later grant(). See the SDK reference → Consent.

Erasure requests

For data-subject erasure or access requests, work through your account and Data Processing Agreement rather than the ingestion API — this REST surface is for sending events, not for fulfilling rights requests.

Next

• Consent API — the /v1-consent record / read endpoint in full.
• Web SDK → Consent — grant / deny / hasConsent and consentMode.
• Identity stitching — where the fingerprint would otherwise act as a signal.
• Event ingestion — the context.consent and context.fingerprint fields.

Last updated 2026-06-10