Developer Guide

Add the SDK to your site, capture consent, verify it on your server, and manage consent records and data-subject rights requests with the Digital Anumati APIs.

Overview

The Digital Anumati web SDK renders the cookie banner and data-collection notices on your site and records each visitor's decisions. Because the browser doesn't know who the visitor is, your backend then verifies each submission, which links the consent to your own id for that person.

Platform capabilities

Installation

Install the SDK

Load the SDK once, as early as possible, so it's ready before any trigger fires. On the web, add it inside <head>; in mobile apps (Android, iOS, Flutter, React Native), initialize it at app launch. Pick your platform below and replace YOUR_SITE_KEY and YOUR_APPLICATION_ID with the values from your application in the dashboard.

1// Next.js — add to app/layout.tsx
2import Script from "next/script";
3 
4export default function RootLayout({ children }: { children: React.ReactNode }) {
5  return (
6    <html lang="en">
7      <head>
8        {/* Digital Anumati Consent SDK */}
9        <Script
10          src="https://cdn.digitalanumati.com/widget/uat/v1/anumati-dpdp-consent-v1.js"
11          data-site-key="YOUR_SITE_KEY"
12          application-id="YOUR_APPLICATION_ID"
13          strategy="beforeInteractive"
14        />
15      </head>
16      <body>{children}</body>
17    </html>
18  );
19}

Notice types

Digital Anumati supports two notice types. A cookie banner is shown to anonymous visitors on page load, while a data collection notice appears on a form or action such as login, booking, contact, upload, or account access and is linked by a trigger key.

Each data collection form is linked to a configured trigger key such as login_account_data_processing_consent, home_collection, contact_us, or upload_prescription. Ask your Digital Anumati admin for the trigger keys used in your application.

Usage

Show a data collection notice on triggers

Configure a trigger in the dashboard (for example signup_click or checkout_submit), then mark any element on your page with da-trigger. When the visitor activates it, the SDK opens the data-collection notice so they can review and consent before the action proceeds.

1<form action="/checkout" method="POST">
2  <button type="submit" da-trigger="checkout_submit">
3    Complete purchase
4  </button>
5</form>

When the visitor submits, the SDK returns a transactionId. Send it to your backend together with the form data.

End-to-end flow

1. 1

   Initialize the session

   Call Session init once per page load before any other widget request so the visitor identity and browser cookies are created.

2. 2

   Fetch the notice

   Call Get notice with bannerType=cookie or data_collection and the relevant triggerKey to load the published purposes and data elements.

3. 3

   Render the form

   Show the banner or form fields, including required purposes and the specific data element descriptions for each purpose.

4. 4

   Submit consent decisions

   Send one decision per purpose shown, with granted/rejected/withdrawn statuses and the purposeId returned by the notice response.

5. 5

   Verify on the server

   Pass the returned transactionId and consentId to your backend and call Transaction verify using your referenceId for the person.

The browser never decides the person's identity. It only records the decision for a visitor or form flow. Your backend is the system of record that says “this consent belongs to person X and is now linked with referenceId Y.”

Decision rules

Browser APIs

All API paths on this page are relative to the base URL https://apis.digitalanumati.com.

Browser calls run from your website JavaScript and must be sent with the browser's session cookies. The request must come from the URL registered on the application and include credentials: 'include' so the cookies are stored and sent with later requests.

1fetch(url, {
2  method: 'POST',
3  credentials: 'include',
4  headers: { 'Content-Type': 'application/json' },
5  body: JSON.stringify(payload)
6});

Session init

Creates or reuses a visitor identity and stores a short-lived session along with cookies such as _da_pid, _da_fp, _da_did, and _da_sid.

Get notice

Returns the published notice for rendering: the purpose list, data elements, descriptions, and UI settings. For cookie banners, the response says whether the banner should be shown to the visitor. For data collection notices, it contains the triggerKey-specific purpose list for the form.

Submit consent

The request body includes bannerType, one decision per purpose, and optional triggerKey / referenceId. For each purpose, send the purposeId from the notice snapshot and a status.

The response returns transactionId, consentId, referenceId, and a purpose list with the final outcome. Keep the transactionId — your backend needs it for server verification.

Other browser operations

Server verification

Right after your backend saves the form, call Transaction verify with the transactionId and your stable referenceId for the person (for example a customer id, email, or mobile number). This links the consent to that person.

1curl -X POST "https://apis.digitalanumati.com/api/v1/server/transaction/verify" \
2  -H "Content-Type: application/json" \
3  -H "x-api-key: <SERVER_API_KEY>" \
4  -d '{
5    "transactionId": "81e74f0e-6f90-4ed2-9873-da87bd0597aa",
6    "referenceId": "user@example.com",
7    "referenceIdFlag": "email",
8    "referenceInfo": { "email": "user@example.com", "name": "User Name" }
9  }'

Use the returned valid flag and overallStatus to decide whether the required consent was given before you continue (for example, before creating a booking). Prefer transactionId so each form submission is verified on its own; if the same person already has a consent for the same notice, the API merges it into that record.

Consent lifecycle

After consent is captured and verified, call the server APIs with the x-api-key header to list records, inspect purpose histories, and change lifecycle state for a person. Use these for privacy center screens and operational consent management.

Status values

Each record includes a purposeSnapshot, the data-element snapshot, retention snapshot, expiry date, and history — use it for a consent detail screen or to audit when a user changed a purpose decision.

DPR requests

A Data Principal Rights request lets the person exercise a right under the DPDP Act. Each request becomes a ticket in the application with a unique identifier such as DPR-2-184DDEDB and a service-level deadline.

Request details vary by rightType. For example, correction requests include field-level corrections with currentValue and requestedValue, while erasure requests include a consequence acknowledgment and the consentRecordIds to erase.

Reference

Browser cookies used by the widget include _da_pid (visitor id, 1 year), _da_fp (device fingerprint), _da_did (device id), _da_sid (session token), and _da_cs (cookie-banner answer state). If a browser blocks cookies, the API response includes a cookies block — store those values and send them back as request headers on later browser calls.

Troubleshoot

Common errors

Integration checklist