Developers

DPDP Guard SDKs for web, mobile and server

DPDP Guard publishes seven SDKs — web/JavaScript, React Native, Flutter, Android, iOS, Node and JVM — plus a shared API contract package, so you can capture consent, honour data-principal rights and enforce consent in your own apps and backends instead of only through the hosted banner.

Browse the SDKs See platform features →

Every package and version below was verified against its public registry on 26 July 2026. Versions move — the registry link on each card is always current.

What is available today, and where

Seven SDKs are published to public registries. Each row links to the registry page you install from and to that SDK's documentation.

DPDP Guard SDK availability by platform, package name, published version and registry, verified 26 July 2026
Platform	Package	Version	Install from	Docs
Web / JavaScript	@dpdpguard/js	1.0.1	npm	Documentation
React Native	@dpdpguard/react-native	0.1.0	npm	Documentation
Flutter	dpdpguard_flutter	0.1.0	pub.dev	Documentation
Android (Kotlin)	ai.dpdpguard:consent-sdk	0.1.1	Maven Central	Documentation
iOS (Swift)	DPDPGuardConsent	0.1.0	Swift Package Manager	Documentation
Node / TypeScript (server)	@dpdpguard/server	1.0.0	npm	Documentation
JVM — Kotlin / Java (server)	ai.dpdpguard:server-sdk	0.1.0	Maven Central	Documentation
Shared contract package	@dpdpguard/contract	0.2.0	npm	Documentation

Before you go live: the API is enabled per organisation

The packages above are published and installable today. The DPDP Guard/api/v1HTTP surface they call is still being switched on organisation by organisation — while it is off for a workspace, its endpoints respond as though they do not exist. Build against an SDK now, and ask us to enable the API for your organisation before you ship.

Client SDKs

Which SDK do I use in an app?

Client SDKs run inside a browser, a mobile app or a desktop app. They read your published notice, record the data principal's per-purpose consent, gate features on a stored decision, and let people raise data-principal rights requests in-app. None of them can mint their own access token — that stays server-side.

Web / JavaScriptv1.0.1npm ↗

Read notices and record anonymous consent from any JavaScript runtime

@dpdpguard/js

A dependency-light, typed HTTP client for the public part of the DPDP Guard API — organisation lookup, published notices, banner configuration and anonymous consent writes. Use it when you want to build your own consent UI instead of dropping in the hosted banner.

Use case

A product team has a bespoke design system and does not want the hosted banner's markup. They install @dpdpguard/js, fetch the org's published notice and banner configuration, render consent in their own components, and post the visitor's per-purpose choice back with giveConsentAnonymous — so the consent record still lands in DPDP Guard's audit trail.

getOrgBySlug() — resolve an organisation by its public slug
getNoticesForOrg() — fetch the notices published for that organisation
getBannerConfig() — read the banner configuration for a domain
giveConsentAnonymous() — record a pre-login, per-purpose consent decision
DpdpGuardApiError — every non-2xx throws with a stable .code from the shared error catalog

Read the @dpdpguard/js documentation→

Installbash

npm install @dpdpguard/js

Usagets

import { DpdpGuardClient } from "@dpdpguard/js";

const client = new DpdpGuardClient({
  baseUrl: "https://your-deployment.convex.site",
});

const org = await client.getOrgBySlug("acme");
const { notices } = await client.getNoticesForOrg(org.orgId);

await client.giveConsentAnonymous({
  organizationId: org.orgId,
  noticeId: notices[0]._id,
  purpose: "Marketing",
  dataTypes: ["email"],
  anonymousId: crypto.randomUUID(),
});

React Nativev0.1.0npm ↗

Ship DPDP consent and rights screens in a React Native app — no native module

@dpdpguard/react-native

A typed client for DPDP Guard's mobile API that runs entirely on fetch — no turbo module, no native folders, nothing to link. Your app can record consent, raise data-principal requests, and gate features on a stored consent decision.

Use case

An Indian consumer app needs an in-app privacy centre so users can see their consents and file an erasure request without emailing support. The team installs @dpdpguard/react-native, hands the client a short-lived access token minted by their own backend, and builds the screens against listDsrRequests()/createDsrRequest() — with no native build changes in either the iOS or Android target.

DpdpGuardClient + setAccessToken() — attach the short-lived token your backend brokered
getOrganization() / getNotices() — public reads that need no auth
giveConsentAnonymous() and linkAnonymousConsent() — capture consent pre-login, then attach it once the user signs in
listDsrRequests() / createDsrRequest() — build an in-app data-principal rights screen
hasConsent() — gate a feature on a consent decision without a network round-trip

Requirements: No native module, no platform channel — usable from existing RN app code.

Read the @dpdpguard/react-native documentation→

Installbash

npm install @dpdpguard/react-native

Usagets

import { DpdpGuardClient } from "@dpdpguard/react-native";

const client = new DpdpGuardClient({
  baseUrl: "https://your-deployment.convex.site",
});

// Your own backend brokers the token — the service API key never
// ships inside an app bundle.
client.setAccessToken(tokenFromMyBackend);

const { requests } = await client.listDsrRequests();
await client.createDsrRequest({ organizationId, type: "erasure" });

Flutterv0.1.0pub.dev ↗

Add DPDP consent and rights to a Flutter app in pure Dart

dpdpguard_flutter

A typed Dart client over the same mobile API, built on package:http with no platform channel and no plugin registrant — so it works on every Flutter target rather than just the two mobile ones.

Use case

A Flutter team running one codebase across Android, iOS and web needs a single consent path for all three. They add dpdpguard_flutter, capture consent anonymously on first launch with giveConsentAnonymous(), then call linkAnonymousConsent() after sign-up so the pre-login decision is attached to the now-identified data principal — the same code on every platform.

DpdpGuardClient + setAccessToken() — one client for public and authenticated calls
getOrganization() / getNotices() — render your published notice inside the app
giveConsentAnonymous() / linkAnonymousConsent() — capture then attach a pre-login consent
listDsrRequests() / createDsrRequest() — an in-app rights screen
hasConsent() — local consent gating with no network call

Requirements: Dart SDK >=3.3.0 <4.0.0 · Flutter >=3.19.0 · depends only on package:http

Read the dpdpguard_flutter documentation→

Installbash

flutter pub add dpdpguard_flutter

Usagedart

import 'package:dpdpguard_flutter/dpdpguard_flutter.dart';

final client = DpdpGuardClient(
  baseUrl: 'https://your-deployment.convex.site',
);

// Token comes from your own backend, never from a bundled API key.
client.setAccessToken(tokenFromMyBackend);

final org = await client.getOrganization('acme');
final requests = await client.listDsrRequests();

Android (Kotlin)v0.1.1Maven Central ↗

Gate Android features on consent, and compute the audit hash on device

ai.dpdpguard:consent-sdk

A Kotlin library with three independent pieces you can adopt separately: a coroutine HTTP client for the DPDP Guard API, a network-free consent gate, and an HMAC-SHA256 audit-hash function that matches the platform's own canonicalisation.

Use case

An Android team must stop firing their analytics SDK until the user has actually granted the Analytics purpose. They add ai.dpdpguard:consent-sdk, load the banner configuration once at start-up, and wrap every analytics call in hasConsent() — which reads the stored decision locally, so the check costs nothing at the call site and still works offline.

DpdpGuardClient — suspend functions over the DPDP Guard /api/v1 endpoints
hasConsent() — network-free consent gating for use at a call site
computeAuditHash() — HMAC-SHA256 audit-trail hash, kept in step with the platform's canonicalisation by a shared golden-vector test gate
Published to Maven Central and, as an alternative, GitHub Packages

Requirements: minSdk 24 · kotlinx-coroutines (the client's methods are suspend functions) · INTERNET permission

Read the ai.dpdpguard:consent-sdk documentation→

Install (build.gradle.kts)kotlin

dependencies {
    implementation("ai.dpdpguard:consent-sdk:0.1.1")
}

iOS (Swift)v0.1.0Swift Package Manager ↗

Call the DPDP Guard API from Swift with a generated, type-safe client

DPDPGuardConsent

A Swift package whose API layer is generated from the same OpenAPI contract the backend is held to, using Apple's swift-openapi-generator — so a wire-shape change surfaces as a compile error rather than a runtime surprise. Audit hashing uses swift-crypto.

Use case

An iOS team adds a privacy centre to their app and wants the compiler to catch contract drift. They add the package in Xcode, attach their brokered access token with a ClientMiddleware so every generated call carries it, and build their consent and rights screens against the generated operations.

Generated OpenAPI client (DPDPGuardConsentAPI) — operations mirror the published contract exactly
recordConsent / getConsent / withdrawConsent / getBannerConfig flows
Bearer-token auth via a ClientMiddleware, so one place attaches the token to every call
Audit-hash verification built on swift-crypto, gated by the shared golden vectors

Requirements: iOS 14+ / macOS 12+ · swift-tools-version 5.9 · Swift Package Manager

Read the DPDPGuardConsent documentation→

Install (Package.swift)swift

.package(
    url: "https://github.com/dpdp-guard-ai/dpdpguard-ios-sdk.git",
    from: "0.1.0"
)

// then, on your target:
.product(name: "DPDPGuardConsent", package: "dpdpguard-ios-sdk")

Server SDKs

Which SDK do I use on a backend?

Server SDKs hold your service API key. They mint the short-lived access tokens your apps use, check consent before your own code processes personal data, run rights workflows, and verify the signature on inbound DPDP Guard webhooks.

Node / TypeScript (server)v1.0.0npm ↗

Broker tokens, gate processing and verify webhooks from your backend

@dpdpguard/server

The server-side half of the SDK family: it holds your service API key, mints the short-lived access tokens your apps use, checks consent before your own code processes personal data, and verifies the signature on inbound DPDP Guard webhooks.

Use case

A team is wiring a nightly export job that must skip any user who withdrew marketing consent. Their backend installs @dpdpguard/server, calls hasConsent() before adding a record to the export, and verifies inbound webhooks with verifyWebhookSignature() so a forged callback cannot flip a consent state — keeping the service API key on the server, where it belongs.

DpdpGuardClient — typed client for the authenticated endpoints
brokerToken() — mint a short-lived data-principal access token for a known user, then hand it to your app
hasConsent() — a consent gate to call before your own processing runs
verifyWebhookSignature() — validate the X-DPDP-Signature header on inbound webhooks
listDsrRequests() / createDsrRequest() — server-side rights workflows

Read the @dpdpguard/server documentation→

Installbash

npm install @dpdpguard/server

Usagets

import {
  DpdpGuardClient,
  hasConsent,
  verifyWebhookSignature,
} from "@dpdpguard/server";

const client = new DpdpGuardClient({
  baseUrl: "https://your-deployment.convex.site",
  apiKey: process.env.DPDP_SERVICE_API_KEY,
});

// Mint a token for a known user, then hand it to your app.
await client.brokerToken(externalId);

const ok = verifyWebhookSignature(
  webhookSecret,
  rawBody,
  req.headers["x-dpdp-signature"],
);

JVM — Kotlin / Java (server)v0.1.0Maven Central ↗

Add consent enforcement to a Kotlin or Java backend fleet

ai.dpdpguard:server-sdk

The JVM counterpart of the Node server SDK, generated from the same contract onto OkHttp and Moshi. Auth is scoped per client instance rather than to JVM-wide statics, so concurrent clients in a multi-tenant process never race on each other's tokens.

Use case

A bank's Kotlin microservices need to broker data-principal tokens and verify webhook callbacks inside an existing Gradle build. They add ai.dpdpguard:server-sdk, construct one DpdpGuardClient per tenant, and rely on the audit-hash test gate to prove their hashing still matches the platform's — a difference that would otherwise only surface during an audit.

DpdpGuardClient(baseUrl, apiKey) — per-instance auth, safe for multi-tenant server processes
brokerToken() — mint a data-principal access token from a service API key
listDsrRequests() / createDsrRequest() — rights workflows from the JVM
getOrganization() / getNotices() — public reads that need no auth
WebhookVerifier.verify() — validate an inbound webhook signature

Requirements: Gradle with mavenCentral() in your repositories · errors surface as DpdpGuardApiError carrying a stable code

Read the ai.dpdpguard:server-sdk documentation→

Install (build.gradle.kts)kotlin

dependencies {
    implementation("ai.dpdpguard:server-sdk:0.1.0")
}

Shared contract

What keeps every SDK in agreement?

One published package carries the API description, the stable error codes and the audit-hash golden vectors that every SDK is tested against. You rarely install it directly — but it is why a consent record written from an Android phone reconciles with one written from your server.

Shared contract packagev0.2.0npm ↗

One published contract every SDK is generated from and tested against

@dpdpguard/contract

Not an SDK you write code against, but the reason the SDKs agree with each other: a versioned package holding the OpenAPI description of the API, the stable error catalog, and the audit-hash canonicalisation spec with its golden test vectors.

Use case

A platform team runs both the Node and the Android SDK and needs the audit hash computed on a phone to match the hash computed on their server — otherwise the audit trail cannot be reconciled. Because both SDKs run the same golden vectors from this package as a required test, a drift in either implementation fails its build instead of quietly corrupting the trail.

openapi/v1.yaml — the OpenAPI 3.1 description of the HTTP surface
error-catalog.json — the stable error codes SDKs expose as .code, so you branch on a code and not on free text
audit-hash-spec.md + audit-hash-vectors.json — canonicalisation rules and golden vectors run as a required test gate in the SDKs
Depended on by every published SDK in this family

Read the @dpdpguard/contract documentation→

Install (only if you generate your own client)bash

npm install @dpdpguard/contract

FAQ

SDK questions, answered

Which DPDP Guard SDKs are available today?

Seven, all published to public package registries as of 26 July 2026: @dpdpguard/js 1.0.1 and @dpdpguard/server 1.0.0 and @dpdpguard/react-native 0.1.0 on npm, dpdpguard_flutter 0.1.0 on pub.dev, and ai.dpdpguard:consent-sdk 0.1.1 (Android) and ai.dpdpguard:server-sdk 0.1.0 (JVM server) on Maven Central. The iOS SDK, DPDPGuardConsent, installs through Swift Package Manager from tag 0.1.0. They share one published contract package, @dpdpguard/contract.

Do I need an SDK to use DPDP Guard?

No. The fastest path to a live consent banner is the copy-paste install script from DPDP Guard's Implementation guide, which needs no SDK wiring at all. The SDKs exist for cases the hosted banner cannot cover: a native mobile app, a bespoke consent UI, or backend code that must check consent before it processes personal data.

Is the DPDP Guard /api/v1 API generally available?

Not yet. The SDK packages themselves are published and installable today, but the /api/v1 HTTP surface they call is being switched on organisation by organisation during rollout — while it is off for a workspace its endpoints respond as if they do not exist. Install and build against an SDK now, and ask us to enable the API for your organisation before you go live.

Which SDK should I install for my platform?

For a React Native app, @dpdpguard/react-native. For Flutter, dpdpguard_flutter. For a native Android app, ai.dpdpguard:consent-sdk. For a native iOS or macOS app, the DPDPGuardConsent Swift package. For a Node backend, @dpdpguard/server. For a Kotlin or Java backend, ai.dpdpguard:server-sdk. For a browser or any other JavaScript runtime where you are building your own consent UI, @dpdpguard/js.

Do the React Native and Flutter SDKs need a native module?

No. Both are plain HTTP clients — the React Native SDK runs on fetch and the Flutter SDK on package:http — with no turbo module, no platform channel and no native folders to link. That is a deliberate design decision, not a gap: the Android and iOS SDKs are separately versioned native libraries, and bridging to them would tie every hybrid release to whichever native version happened to be vendored alongside it.

Can a mobile app mint its own DPDP Guard access token?

No, and by design. Minting a data-principal access token requires a service API key, which is extractable from any app binary and must never be shipped in one. The mobile and hybrid SDKs therefore omit the token-broker call entirely: your own backend holds the API key, calls the broker endpoint using @dpdpguard/server or ai.dpdpguard:server-sdk, and passes the resulting short-lived token to the app via setAccessToken(). The same reasoning keeps audit-hash and webhook-signature code out of the client SDKs — both need a server-held HMAC secret.

What is @dpdpguard/contract and do I need to install it?

@dpdpguard/contract is the published package that holds the OpenAPI description of the API, the stable error catalog, and the audit-hash canonicalisation spec with its golden test vectors. You do not normally install it — every SDK already depends on it. Install it directly only if you are generating your own client for a language the SDK family does not cover yet.

How do the SDKs keep the DPDP audit trail consistent across platforms?

Every SDK that computes an audit hash runs the same golden vectors from @dpdpguard/contract as a required test, so a hash produced on Android, on iOS or on a server must match the platform's own canonicalisation or that SDK's build fails. This matters for evidence: a consent audit trail is only defensible under India's Digital Personal Data Protection Act, 2023 if records written from different clients reconcile.

How do SDK errors work?

Every non-2xx response raises a DpdpGuardApiError — the same name in the TypeScript, Dart and Kotlin SDKs — carrying the HTTP status and a stable code drawn from the shared error catalog in @dpdpguard/contract. Branch on the code, never on the free-text message: the codes are part of the versioned contract, the messages are not.

Are the DPDP Guard SDKs open source?

The source for all of them is public on GitHub under the dpdp-guard-ai organisation. The JavaScript, Node, React Native and Flutter SDK repositories carry an MIT licence; the shared @dpdpguard/contract package is Apache-2.0. The Android, iOS and JVM repositories do not yet declare a licence file, so treat their terms as unspecified until they do.

How are the SDKs versioned against the API?

Three axes move independently: the wire API's major version lives in its URL path (/api/v1), the shared @dpdpguard/contract package follows semantic versioning, and each SDK carries its own semantic version on its own registry. A breaking contract change — a newly required field, a removal, an error-code change, or any change to audit-hash canonicalisation — forces a major bump in the SDKs that consume it, and an audit-hash change additionally requires a human sign-off before anything downstream is published.

Prefer no code at all?

The hosted consent banner installs from a copy-paste snippet — no SDK wiring required. Start there, and reach for an SDK when you need a native app, a bespoke consent UI, or a server-side consent gate.

Start for free →