<!-- markdown mirror of https://mintid.net/en/sdk — generated at build time -->

> One verifying core, three ways to consume it: embed the Python SDK, self-deploy it as a service, or talk to your own service through a transport-only client.

index — 12 documents

1.  [overviewsdk/00](/en/sdk)
    *   [one verifying core](#one-core)
    *   [what you cannot turn off](#invariants)
    *   [the decision model](#decision-model)
2.  [getting startedsdk/01](/en/sdk/getting-started)
3.  [python sdksdk/02](/en/sdk/python)
4.  [service modesdk/03](/en/sdk/service-mode)
5.  [typescript clientsdk/04](/en/sdk/typescript-client)
6.  [mcp serversdk/mcp](/en/sdk/mcp-server)
7.  [conformancesdk/05](/en/sdk/conformance)
8.  [reason codessdk/06](/en/sdk/reason-codes)
9.  [adr-0001 · kyc trust modeladr/0001](/en/sdk/adr-0001-kyc-trust-model)
10.  [adr-0002 · packagingadr/0002](/en/sdk/adr-0002-packaging)
11.  [adr-0003 · multi-languageadr/0003](/en/sdk/adr-0003-multilanguage)
12.  [bip-0001 · contract freezebip/0001](/en/sdk/bip-0001-verifier-service-contract)

SDK docs · sdk/00

# Integration overview

One verifying core, three ways to consume it: embed the Python SDK, self-deploy it as a service, or talk to your own service through a transport-only client.

MintID lets a **verifier agency** (a relying party: a bank, a marketplace, a platform) accept privacy-preserving identity presentations: a holder proves _predicates_ — "over 18", "KYC grade at least A3", "credential active" — without revealing attributes, documents or identifiers. The SDK is how your backend asks for and validates those presentations.

## One verifying core, three ways to consume it

Every deployment runs the **same single verifying core** (the Python SDK with its pinned Rust proof engine). Nothing else ever validates a presentation — that is a protocol rule (the single-core rule of the specification), not a packaging convenience.

Mode

What you run

For whom

Embedded

Your Python backend imports `mintid-verifier-sdk` and calls `validate_presentation` in-process

Python backends; lowest latency, fewest moving parts

Service

The same SDK wrapped in a thin first-party HTTP service you self-deploy next to your backend

Any backend language; operational isolation

Client

`@mintid/verifier-client` (TypeScript, Node) — a transport-only client of **your own** service instance

Node/TypeScript backends (PHP next)

Two things follow from "transport-only" and are worth internalizing:

*   **Clients carry no cryptography and no policy.** The TS client is a few hundred lines of HTTP; it cannot verify, cache, weaken or skip anything. If your client-side code ever seems to need a verification feature, the feature belongs to the service.
*   **The service is yours.** Pointing your client at somebody else's verifier service would delegate the _decision_ itself. Service mode adds transport, never authority.

## What the SDK enforces that you cannot turn off

These are constants and closed types in the code — not configuration:

1.  **The nine acceptance conditions run in full, in order**, on every presentation: active verifier and exact origin on proven chain state; registered request key; unused nonce; inside the deadline; proof bound to the exact challenge (origin, verifier id, request key, nonce, policy, finalized chain height); every requested predicate proven; issuer operational with a current status root; a final proven-state recheck; and irreversible nonce consumption as the accept gate.
2.  **Presentations live 10 seconds.** The lifetime is a constant.
3.  **Chain reads are proven or they don't count.** Every RPC answer is verified with cryptographic (ics23) proofs against a trust anchor; claimed absence of a record fails closed. There is no "trust this node" mode.
4.  **Retention is a closed schema.** The only thing kept is a minimal decision record — session id, outcome, reason code, a 32-byte context digest, timestamp. Proof bytes, claim values and personal data structurally do not fit.

## The decision model

Validation returns a **decision**, never throws for a rejection. `reason_code` comes from a **closed vocabulary** shared byte-for-byte across the Python SDK, the HTTP contract and every client — see [reason codes](/en/sdk/reason-codes). Transport-level problems (malformed body, service refusing to work from unproven chain state) are errors; domain rejections are data.

Where to go next:

1.  [Getting started](/en/sdk/getting-started) — verifier obligations first, then installation channels and current status.
2.  [Python SDK](/en/sdk/python) — the embedded mode.
3.  [Service mode](/en/sdk/service-mode) — the deployable + the OpenAPI contract.
4.  [TypeScript client](/en/sdk/typescript-client).
5.  [Conformance & versioning](/en/sdk/conformance) — how "every SDK behaves identically" is enforced, and what our version numbers promise.

decisionsdk/00 · verbatim

```
{ accepted: true,  reason_code: "accepted", verified: { issuer_id, status_root, proven_predicates } }
{ accepted: false, reason_code: "nonce_replayed", verified: null }
```

[nextgetting started →](/en/sdk/getting-started)

---
Source: https://mintid.net/en/sdk · Integration overview — MintID verifier SDK docs