Quickstart

From pip install to your first signed proof in four steps. The SDK is open source, Apache-2.0.

1

Install the SDK

Neither package is published yet — no PyPI release, no npm release — so the SDK installs from a clone. The Node.js equivalent is in its own quickstart.

git clone https://github.com/idside-eu/idside-sdk.git
pip install -e 'idside-sdk/packages/python[openai]'

2

Set your secret key

Create an app in the dashboard and issue a secret key. It is shown once, at creation — treat it like any other backend secret.

export IDSIDE_API_KEY="sk_live_…"

3

Wrap your client

One change: wrap the client, pass a user_id. Everything else in your codebase stays as it was.

from idside import consent
from openai import OpenAI

client = consent.wrap(OpenAI())

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}],
    user_id="usr_marie_456",  # your identifier, pseudonymized before it reaches us
)

On each call the SDK resolves the user's consent, forces the provider's privacy parameters (e.g. store=false), attaches a signed ACT token, and appends a ledger entry. If ID Side is unreachable it raises ConsentUnreachableError and the provider is never called — catch it and degrade your feature, not your compliance.

4

Verify a proof

Every response carries its token id. Anyone can check a token's status — no account, no API key:

curl https://api.idside.eu/v1/verify/act_01j9… → { "status": "valid", "provider": "openai", "legal_basis": "consent", … }

The API contract

Every endpoint, every field, every error — as an OpenAPI 3.1 document, served by the API itself so that what you generate a client from is what this deployment actually implements. A test in our build fails if a route and the document disagree. Point your generator straight at it:

curl https://api.idside.eu/openapi.yaml

Errors are RFC 9457 problem documents with a stable type URL — branch on that, never on the message. And read the document before integrating by hand: the parameters an authorization returns are not advisory, they are the half of the product that makes the proof true.

Read the contract →

Public keys (JWKS)

ACT tokens are ES256 JWTs. Fetch our public keys and verify signatures entirely offline, in any JWT library:

GET /.well-known/jwks.json

ACT token specification

The full claim set — request hash, nonce, TTL, consent source, legal basis — is specified in the open-source repository, next to the SDK code that produces it.

github.com/idside-eu/idside-sdk →

Providers

OpenAI, Anthropic, Gemini and Mistral are supported today. What can actually be enforced differs per provider — some expose a real per-request parameter, some give a contractual commitment, some train on free-tier data with no API-level opt-out at all. Each provider in your dashboard carries a trust level with sources and a last-verified date, so you can see exactly what your proof covers.

Adding a provider is an adapter and a registry entry — the enforcement mapping lives server-side, so provider API changes never require an SDK upgrade.

Create your first app