Developers

DPDP Guard SDKs for web, mobile and server

DPDP Guard publishes eight SDKs — web/JavaScript, React Native, Flutter, Android, iOS, Node, Python 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 spot-checked directly against its public registry again on 28 August 2026 — @dpdpguard/contract's npm listing still reports 1.6.0, latest published 24 August, unchanged. That release is a minor, additive change adding one endpoint, GET /api/v1/consent-status, and no client/server SDK consumes it yet. The iOS SDK (DPDPGuardConsent) has moved twice since this page began tracking it: to 1.2.0 (syncing to contract 1.6.0) and then to 1.3.0, adding on-device offline consent capture with Secure Enclave signing. Every other SDK is unchanged since the last check. Versions move — the registry link on each card is always current.

What is available today, and where

Eight SDKs are published to public registries — npm, PyPI, pub.dev, Maven Central and Swift Package Manager. 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 28 August 2026
Platform	Package	Version	Install from	Docs
Web / JavaScript	@dpdpguard/js	2.1.0	npm	Documentation
React Native	@dpdpguard/react-native	2.0.0	npm	Documentation
Flutter	dpdpguard_flutter	1.1.0	pub.dev	Documentation
Android (Kotlin)	ai.dpdpguard:consent-sdk	1.2.0	Maven Central	Documentation
iOS (Swift)	DPDPGuardConsent	1.3.0	Swift Package Manager	Documentation
Node / TypeScript (server)	@dpdpguard/server	2.1.0	npm	Documentation
Python (server)	dpdpguard-sdk	1.1.0	PyPI	Documentation
JVM — Kotlin / Java (server)	ai.dpdpguard:server-sdk	1.1.0	Maven Central	Documentation
Shared contract package	@dpdpguard/contract	1.6.0	npm	Documentation

Ready to go live: service keys are self-serve

The packages above are published and installable today, and the full DPDP Guard/api/v1HTTP surface is live for every organisation — organisation lookup, published notices, banner configuration and anonymous consent capture need no key at all, and the authenticated methods (token brokering, consent gating, server-side DSR/grievance workflows) work as soon as you generate your own service API key from the Integrations page in your dashboard. No request to us, no waiting period.

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 / JavaScriptv2.1.0npm ↗

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 Nativev2.0.0npm ↗

Ship DPDP consent, rights screens and offline capture in a React Native app

@dpdpguard/react-native

A typed client for DPDP Guard's mobile API, plus a native module for offline consent capture. Your app can record consent, raise data-principal requests, gate features on a stored consent decision, and — since 2.0.0 — capture and sign consent with zero connectivity for later sync.

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(). A field-sales variant of the same app captures consent at a doorstep with no signal at all, using OfflineCaptureManager to sign and hold it locally until the device is back online.

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
OfflineCaptureManager — signs a consent capture with a Secure-Enclave/StrongBox-backed device key, persists it AES-256-GCM-encrypted on-device with zero network I/O, then batches and syncs it once connectivity returns

Requirements: Requires React Native's New Architecture (declares react/react-native peer dependencies) for the native offline-capture module; the HTTP client itself is plain fetch.

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" });

Flutterv1.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)v1.2.0Maven Central ↗

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

ai.dpdpguard:consent-sdk

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

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
OfflineCaptureManager — capture() signs and persists a consent with zero network I/O via a StrongBox-or-TEE-backed, non-exportable ECDSA P-256 key; syncPending() batches up to 200 sessions to the server and evicts every acknowledged one
samples/consent-demo — a runnable Android module walking the whole guest-consent flow end to end
Published to Maven Central and, as an alternative, GitHub Packages

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

Read the ai.dpdpguard:consent-sdk documentation→

Install (build.gradle.kts)kotlin

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

iOS (Swift)v1.3.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, and consent captured with no connectivity is signed and queued on-device until the app can sync it.

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. A field-sales variant of the same app captures consent at a doorstep with no signal at all, using OfflineCaptureManager to sign and hold it locally until the device is back online.

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
OfflineCaptureManager — signs a consent capture with a Secure-Enclave-backed (or Keychain-fallback) device key, persists it AES-256-GCM-encrypted on-device with zero network I/O, then batches and syncs it once connectivity returns

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: "1.3.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)v2.1.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"],
);

Python (server)v1.1.0PyPI ↗

Check consent from a Python backend before you process personal data

dpdpguard-sdk

The Python counterpart of the Node server SDK, hand-maintained to mirror it method for method — so auth modes, idempotency headers, error codes and audit-hash canonicalisation behave identically whichever of the two your service is written in. Ships type hints and a py.typed marker.

Use case

A Django team runs the CRM that decides which customers get a marketing email. Before each send they call has_consent() against the principal's consent records, and they verify inbound DPDP Guard webhooks with verify_webhook_signature() so a forged callback cannot flip a consent state. The service API key stays in their backend environment, and the SDK's audit-hash helpers let them confirm a consent record they received matches the platform's own canonicalisation.

DpdpGuardClient — typed client over /api/v1, usable as a context manager that closes its httpx.Client
broker_token() — mint a short-lived data-principal access token from your service API key, then hand it to your app
create_dsr_request() / list_dsr_requests() — rights workflows, with an optional Idempotency-Key so a retried request cannot double-write
has_consent() — a pure consent gate to call before your own processing runs
verify_webhook_signature() — constant-time HMAC-SHA256 check on the X-DPDP-Signature header
compute_audit_hash() / canonicalize_audit_event() — audit hashing tested against the same golden vectors as every other SDK

Requirements: Python 3.9+ · one runtime dependency (httpx) · ships py.typed, so mypy sees the types · install with pip or `uv add dpdpguard-sdk` · imported as `dpdpguard`

Read the dpdpguard-sdk documentation→

Installbash

pip install dpdpguard-sdk

Usagepython

import os
from dpdpguard import DpdpGuardClient, has_consent, verify_webhook_signature

client = DpdpGuardClient(
    "https://your-deployment.convex.site",
    # Required for broker_token(); keep it in your server environment.
    api_key=os.environ["DPDP_SERVICE_API_KEY"],
)

# Mint a token for a known user, then hand it to your app.
client.broker_token(external_id)

# Public reads need no auth at all.
org = client.get_organization("acme")

ok = verify_webhook_signature(webhook_secret, raw_body, signature_header)

JVM — Kotlin / Java (server)v1.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 · MIT licensed

Read the ai.dpdpguard:server-sdk documentation→

Install (build.gradle.kts)kotlin

dependencies {
    implementation("ai.dpdpguard:server-sdk:1.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 packagev1.6.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. The published 1.6.0 package now carries info.version 2.9.0, matching this repository's copy (re-confirmed against npm directly on 24 August 2026, dist-tags.latest = 1.6.0), for the GET /api/v1/consent-status route
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, byte-identical in every published contract version to date
Consumed by every SDK in this family — as of 12 August 2026 all eight have synced to the current contract generation, closing the Flutter/iOS gap this page tracked through 11 August (see the FAQ below)

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?

Eight, all published to public package registries, plus the shared @dpdpguard/contract package they're built against. Verified live directly against each registry on 31 August 2026: @dpdpguard/js 2.1.0 and @dpdpguard/server 2.1.0 on npm, @dpdpguard/react-native 2.0.0 on npm, dpdpguard-sdk 1.1.0 (Python) on PyPI, dpdpguard_flutter 1.1.0 on pub.dev, and ai.dpdpguard:consent-sdk 1.2.0 (Android) and ai.dpdpguard:server-sdk 1.1.0 (JVM server) on Maven Central. The iOS SDK, DPDPGuardConsent, installs through Swift Package Manager from tag 1.3.0. All three mobile client SDKs — iOS (1.3.0, 24 Aug), Android (1.2.0, 29 Aug) and React Native (2.0.0, 29 Aug) — now ship the same on-device offline consent capture, signing a capture with a Secure-Enclave- or StrongBox/TEE-backed device key so field agents can record consent with zero connectivity and sync later; React Native's release is a major bump because it now requires the New Architecture for that native module. Six of the eight had cut a major release earlier, on 29 July 2026, because the shared contract package published its one breaking version to date and the versioning policy forces a major bump in everything that consumes it.

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?

Yes, fully, as of 14 August 2026. The public and session-authenticated parts — organisation lookup, published notices, banner configuration, anonymous consent capture, and the staff DSR/grievance endpoints that reuse a DPO's own dashboard login — have been live for every organisation since 24 July 2026. What used to require asking us first was minting a NEW service API key, which the authenticated server-SDK methods (brokerToken(), hasConsent(), server-side DSR/grievance workflows) need: convex/apiKeys.ts's create mutation previously called a requireCmApiEnabled check that blocked it platform-wide. That check no longer exists — the platform's entire feature-flag system was removed on 14 August 2026, and a direct read of the current create mutation confirms it now inserts a new service key unconditionally for any signed-in fiduciary admin or DPO. Generate your own key from the Integrations page (/dashboard/fiduciary/integrations) and start calling the authenticated methods immediately — no request to us required.

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 Python backend — Django, FastAPI, Flask or a plain worker — dpdpguard-sdk. 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.

Is there a Python SDK for DPDP Guard?

Yes. dpdpguard-sdk is DPDP Guard's official Python server SDK, published on PyPI at version 1.1.0 (MIT licensed, Python 3.9 and newer). Install it with `pip install dpdpguard-sdk` or `uv add dpdpguard-sdk` and import it as `dpdpguard`. It is hand-maintained to mirror the Node reference SDK, @dpdpguard/server, method for method, so a Django, FastAPI or Flask backend gets the same behaviour a Node one does: a typed client over /api/v1, token brokering for your apps, DSR and grievance workflows, a consent gate to call before your own code processes personal data, HMAC-SHA256 verification of inbound webhook signatures, and audit-hash helpers tested against the same golden vectors as every other DPDP Guard SDK. It has one runtime dependency, httpx, and ships type hints with a py.typed marker. It replaces the earlier advice to generate your own Python client from the OpenAPI description — generation remains the documented fallback only for languages without an official SDK.

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, dpdpguard-sdk (Python) 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. Its latest published version is 1.6.0 (npm, Apache-2.0), published 24 August 2026, carrying OpenAPI description version 2.9.0 for one new endpoint, GET /api/v1/consent-status — minor and purely additive, so it forced no breaking change and no SDK release (none of the eight consumes that endpoint directly; it backs the in-dashboard Consent Status Lookup console instead). The prior release, 1.5.0 (11 August 2026, OpenAPI 2.8.0), did prompt all eight SDKs to sync to it as a routine minor bump on 11-12 August, which is also what finally brought Flutter and iOS onto the current contract generation. You do not normally install it — every SDK is built against it. Install it directly only if you are generating your own client for a language the SDK family does not cover yet, or if you want to validate your own requests against the same schemas the API is held to.

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.

Do any of the SDKs cover the /mcp/v1 agent surface?

No. All eight SDKs are clients for the /api/v1 HTTP surface. DPDP Guard also has a second, separately versioned surface at /mcp/v1 for AI agents, and @dpdpguard/contract 1.2.0 (31 July 2026) added eleven error codes that belong to it — SCOPE_INSUFFICIENT, TOOL_NOT_AVAILABLE, ORG_DISABLED, APPROVAL_REQUIRED, APPROVAL_BACKLOG_FULL, PROPOSAL_EXPIRED, SECOND_REVIEWER_REQUIRED, PROPOSAL_ALREADY_REVIEWED, DATA_VOLUME_EXCEEDED, PLAN_LIMIT_REACHED and AGENT_WRITE_BLOCKED. If you read the shared error catalog you will see them, so it is worth knowing what they are: none of the eleven is ever returned by an /api/v1 endpoint, and no SDK on this page implements or calls the /mcp/v1 surface at all — it is a separate integration surface for AI agents, not something any of these eight SDKs is meant to cover. Nothing about the codes changes how the eight SDKs behave; they were the only content of contract 1.2.0, which is why that release moved no SDK version.

Are the DPDP Guard SDKs open source?

Mostly, yes. The source for all of them is public on GitHub under the dpdp-guard-ai organisation. Seven of the eight are MIT licensed: the JavaScript, Node, React Native, Flutter and Python repositories each carry an MIT LICENSE file, the Python package additionally declares MIT in its PyPI metadata, and both Maven Central artefacts — ai.dpdpguard:consent-sdk (Android) and ai.dpdpguard:server-sdk (JVM) — declare MIT in the POM published alongside them. The shared @dpdpguard/contract package is Apache-2.0. The one exception is the iOS SDK, DPDPGuardConsent, which declares no licence in its repository or its package manifest, so treat its terms as unspecified until it does.

Which SDKs are built against the current contract, and which are not?

As of 12 August 2026, all eight are on the current 1.x generation of @dpdpguard/contract for the first time. @dpdpguard/js, @dpdpguard/server and @dpdpguard/react-native each depend on the contract package by range; ai.dpdpguard:server-sdk generates its client from the current OpenAPI description; and ai.dpdpguard:consent-sdk (Android) and dpdpguard-sdk (Python) hand-maintain their models against the current conformance data, all re-synced in the same 11-12 August window. Flutter and iOS had lagged behind on the older 0.2.0 schemas since this page began tracking them — Flutter's 1.0.0 was written but blocked from publishing by a tag-push restriction, and iOS's 1.0.0 tag had bumped its version number without re-vendoring the schemas — and both gaps closed in this window: dpdpguard_flutter published straight to 1.1.0 once the publish block cleared, and DPDPGuardConsent's 1.1.0 tag re-vendors the OpenAPI description and error codes it had been missing. Historically this mattered for one thing — request validation. Contract 1.0.0 was a deliberately breaking release that added non-empty constraints (minLength: 1 / minItems: 1) to the consent, grievance and nomination request bodies, so a call that the older 0.2.0 schemas would have accepted with an empty string or an empty array returns a 400 from the API; that gap is now closed for every SDK, but still branch on the error code from the shared catalog rather than the free-text message if you do get a 400. Every contract release since the 1.0.0 breaking change — through 1.6.0 — has been purely additive and changed nothing for any SDK's existing behaviour: new endpoints are flag-gated, several are backend-only or consumed only by an in-dashboard console rather than an SDK, and none touches an existing endpoint, field or error code. Audit-hash canonicalisation and the persisted consent-record shape have not changed in any release: the golden audit-hash vectors are byte-identical from 0.2.0 through 1.6.0 and in every SDK's vendored copy, so consent evidence written from any of the eight still reconciles.

Was the Flutter SDK ever blocked from publishing?

Yes, for several weeks, and it is resolved now. dpdpguard_flutter 1.0.0 was written, committed and passing CI well before it could actually be installed: pub.dev's automated publishing only trusts a workflow run triggered by a version tag, and the publishing environment could not push tags, so pub.dev kept serving the older 0.1.0 the whole time — a version number sitting in a repository is not something a developer can install. That restriction cleared on 12 August 2026, and because 1.0.0 itself was never published, the release jumped straight from 0.1.0 to 1.1.0, landing on the current contract generation in the same step. If you installed 0.1.0 before this date, upgrade to 1.1.0 — its request validation now matches every other SDK's rather than the older 0.2.0 schemas.

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. That policy is why six SDKs released a new major version on 29 July 2026 with no functional change of their own: contract 1.0.0 was classified breaking, so the bump was mandatory rather than discretionary. It also means an SDK's major number tells you which contract generation it belongs to, not how much its own API moved. The reverse case is just as visible on this page, six times over: contract 1.1.0 (30 July 2026) added three read-only partner routes for a fiduciary's own backend, 1.2.0 (31 July 2026) added eleven error codes for the separate /mcp/v1 agent surface, 1.3.0 (4 August 2026) added one server-integration endpoint for offline/QR consent links, 1.4.0 (8 August 2026) added the offline-capture surface plus a Consent Gate decision endpoint, 1.5.0 (11 August 2026) added two more Consent Gate observability endpoints plus a documentation-only key-versions section, and 1.6.0 (24 August 2026) added the GET /api/v1/consent-status identifier-resolution endpoint. All six are minor, purely additive releases that touch no existing endpoint, field or error code, so none was legally required to force an SDK release — 1.5.0 was still used as the occasion for a routine, voluntary sync across all eight SDKs on 11-12 August 2026 (see the versions listed above), which is what finally brought Flutter and iOS off the older 0.2.0 schemas the first four additive releases had left them on, and 1.6.0 moved no SDK because nothing consumes its one new endpoint. The OpenAPI description carries its own version too, separate from both the /api/v1 path and the contract package's own semver — it has moved from 2.4.1 up to 2.9.0 across these six releases as new (mostly flag-gated) endpoints were documented.

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 →