Independently callable API surfaces sharing one compliance core: matching engine, audit logging, and data-handling rules. Public docs, a published OpenAPI spec, and a quickstart for each, no signup wall. Every service runs in sandbox mode by default, serving synthetic data so you can see the real request and response shape before switching on a production credential.
Everything below is the real API reference, for calling it yourself. If you'd rather talk to a person than curl, get started puts you on the waiting list and we take it from there.
Standalone AML/PEP/sanctions screening - POST /v1/screen. Runs the 4-layer hybrid matching engine (exact, full-text, Levenshtein, phonetic) and returns a CLEAR / POSSIBLE_MATCH / CONFIRMED_MATCH classification with a full explain trace.
Quickstart → · API reference →
How screening works → · Screening rules →
New to EUDI wallets? Read what an EU Digital Identity Wallet is, and how a session works before the Verify API, Age API, Nexiel Login, and In-Store Age Verification sections below assume you already know what OpenID4VP, DCQL, and SD-JWT VC mean.
Every aml-identity check in Verify API, and every Screen API decision, is delivered as an encrypted evidence pack instead of stored as PII. Read how to generate and register the key that decrypts it.
Identity verification - EUDI wallet sessions (POST /v1/verify/sessions) for age verification and AML identity checks.
Quickstart → · API reference →
Age verification for age-restricted online services, built on top of Verify API's existing EUDI wallet stack - not a separate identity-verification engine. Same POST /v1/verify/sessions route as above, with checkType: "age-verification", requesting only the wallet's birthdate claim, used solely to compute an age_over_18 boolean and discarded immediately, and nothing else about the holder.
Quickstart → · API reference (shared with Verify API) →
Sign in with EUDI Wallet, packaged as a standard OIDC identity provider connection - your Keycloak, Auth0, or Okta broker adds Nexiel the same way it adds Google, with no OpenID4VP or DCQL code of its own. Built on Verify API's existing engine (checkType: "login-authentication"), not a new identity-verification engine. Sandbox mode is real and usable today; production needs a still-unfiled relying party registration and the same EU PID-Provider trust infrastructure every other PID-based Nexiel check depends on.
Academic credential issuance for universities and other accredited institutions - degree, module, and enrolment credentials signed with an institution's own key and delivered into a student's EUDI wallet. Single-credential and batch issuance are both real and tested end to end. Not yet deployed to production.
How credential issuance works →
Extends Nexiel Age's remote EUDI wallet flow to a physical checkout - alcohol, tobacco, and lottery purchases, each independently country-and-category gated, since a single country can already have three different legal answers across those three categories. Same route as every other Nexiel Verify check: only the checkType and a required countryCode field differ. Every (country, category) pair defaults to not supported. Only a human reviewer's explicit dashboard action can enable one.
Verifies a wallet-held mobile driving licence (mDL, ISO/IEC 18013-5) instead of a PID - given name, driving privileges, document number, and issuing country. Same POST /v1/verify/sessions route as every other check type, with checkType: "mobile-driving-licence". Gated: a production request needs an approved checkType entitlement from the dashboard, on top of an active Verify account.
Confirms whether a named natural person currently has authority to sign for a specific company, alone or jointly, via the EWC RB-004 Signatory Rights attestation instead of a PID. Same POST /v1/verify/sessions route as every other check type, with checkType: "corporate-mandate-verification". Gated, the same entitlement system mobile driving licence uses.
A 0-100 risk score for a cryptocurrency wallet address (POST /v1/wallet-risk/score), derived from real, open-licensed GraphSense TagPacks attribution data. A separate, scored signal from Screen API's exact-match wallet sanctions screening above - use either, both, or neither. Real and working today, but a preview surface: not yet a billed, generally available product.
A Qualified Electronic Signature (QES, eIDAS Art. 3(12)) on a PDF document, attributed to one specific natural person rather than a company. Same Screen API service as sanctions and PEP screening, one route, POST /v1/sign, requiring its own individually provisioned QTSP credential per signer. Requires a real bearer token in every mode, with no sandbox path, and always returns a 503 today: real, tested scaffolding with no QTSP account configured yet.
Official TypeScript (@nexiel/sdk) and Python (nexiel-sdk) clients for Screen API and Verify API: generated request/response types kept fresh against each service's real OpenAPI spec, typed exceptions, and a built-in wait-for-completion helper for EUDI wallet sessions so you never hand-roll your own poll loop.
A real MCP server for pointing a coding agent (Claude Code, Cursor, or your own automated system) at Nexiel Verify and Nexiel Age - initiate and read back sessions with no HTTP client code of your own. Every tool call is authorized by your own restricted API key, checked server-side on every request. The MCP server itself holds no credentials of its own.
Quickstart → · Tool reference →
A real, copy-pasteable prompt for handing an AI coding assistant (Cursor or similar) a genuine Nexiel integration task, one that names real request/response fields instead of inviting it to guess, and says plainly which package not to npm install. A machine-readable /llms.txt covers the same ground for assistants that read it directly.
AI integration guide → · /llms.txt →
Four supervised agents on top of the Screen API above: an Onboarding Agent (POST /v1/onboarding/kyb-applications) that drafts a recommendation from a prospective client's signup input, a KYB Review Copilot (POST /v1/kyb-applications/:id/review-drafts) that summarizes an application's evidence into a draft recommendation for a human reviewer, an EUDI Onboarding Copilot that drafts a client's relying-party registration checklist, and a Legislation Watch Copilot that proposes in-store age verification jurisdiction coverage changes. Every one of them drafts, summarizes, or proposes. None of them can ever apply the decision it is advising on. See the guardrail section on that page for exactly how that is enforced in code, not just in prose.
Deep dives into the exact mechanics behind a specific feature (webhook signing and Idempotency-Key semantics today, more over time), for integrators who already have a working sandbox integration from the quickstarts above. Hosted on, and gated by, the real Nexiel customer dashboard: the same Keycloak sign-in that already protects your API keys, KYB status, and request history.
The Screen API and Verify API reference pages on this site are rendered directly from each service's real, generated openapi.json (produced by @fastify/swagger from the actual Fastify route schemas, not hand-written) - read from disk at build/request time, so there is nothing here to hand-transcribe and let drift from the implementation. The Agent Toolkit's tool reference is hand-written (MCP tools aren't OpenAPI routes), but every parameter and response shape on it matches the real TypeScript tool definitions behind the Agent Toolkit, and the quickstart's example responses reflect real tool-call behavior, not hypothetical output.