APIs & SDKs
Four developer surfaces, one platform. Pick the one that matches your stack — they all hit the same backend, the same data, and the same authenticated session.
Pick your interface
React SDK
Typed React hooks and providers to embed a Keyban wallet, manage sessions, and sign on-chain. The default for any React app.
JavaScript / TypeScript SDK
Headless ESM package shared by the React SDK. Use it directly in Node.js, vanilla web, or non-React frameworks.
Python SDK
PassportClient for server-side Digital Product Passport workflows — typed Pydantic models, certification, IPFS upload.
REST API
The full HTTP surface backing every SDK. Authenticated with X-Api-Key. Reference auto-generated from OpenAPI.
When to pick what
| You're building… | Reach for |
|---|---|
| A React frontend (wallet, DPP scan UI, loyalty dashboard) | React SDK |
| A Node.js backend, a Vue / Svelte / Next app, a CLI | JavaScript SDK |
| A Python service that mints or updates DPP passports server-side | Python SDK |
| Anything else (Go, Ruby, PHP, Rust, no-code) | REST API |
The four surfaces are not exclusive — most production deployments mix them. A typical Loyalty integration uses the React SDK on the storefront and the REST API from the back-office to mint points after a checkout webhook fires on the partner's side.
Coverage matrix
What each surface exposes today. – means « not surfaced at this layer
yet » — the underlying capability still exists, you can usually reach it
via the REST API.
| Capability | React SDK | JS SDK | Python SDK | REST API |
|---|---|---|---|---|
| Embedded Wallet (auth, accounts, signing) | ✅ | ✅ | – | ✅ |
| Digital Product Passport (mint, update, certify) | ✅ | ✅ | ✅ | ✅ |
| On-chain Loyalty (orders, reward tiers, accounts) | ✅ | ✅ | – | ✅ |
| Wallet for Agents | – | – | – | ✅ |
| Imports (catalogue, bulk DPP) | – | – | – | ✅ |
| Admin operations (members, applications, billing) | – | – | – | ✅ (Admin Console preferred) |
Authentication at a glance
| Surface | Mechanism |
|---|---|
| React SDK | Session cookie issued by Keyban Auth |
| JS SDK | Session cookie or X-Api-Key, depending on context |
| Python SDK | X-Api-Key header (passed to the constructor) |
| REST API | X-Api-Key header, with { resource: ['action'] } permissions |
API keys are issued from the Admin Console — there is no public REST endpoint to provision them programmatically. See Permissions & Roles for the full model and the OR-logic between member roles and API key scopes.
Versioning and stability
- REST endpoints carry a major version in the path (
/v1/...). Breaking changes ship behind a new prefix; old versions stay live for the duration documented in the migration note. - TypeScript SDKs follow semver — the changelog
is in each package's
CHANGELOG.md. - Python SDK follows semver against the DPP REST surface it wraps.
- OpenAPI spec is the source of truth — the SDKs are regenerated or hand-tested against it on every release.
Related
- Architecture overview: Security architecture
- Error model: How to handle API errors
- First-call walkthrough: Quick start (React)
- Server-side examples: Node.js integration · Python integration