Policy-gated login & signup
Add a policy step to signup or sign-in: users verify once in a wallet, you call Nexion to check age, region, or eligibility, and your auth service gets a simple Pass/Fail answer plus a policy receipt.
Developer Documentation
Developers
Nexion gives you a wallet-based policy verifier you can call like any other service: send a policy, get back a Pass/Fail decision and a signed receipt—no ID documents in your app.
This page is for engineers and platform teams building sign-up flows, gated features, and crypto products. For the why behind this model, see How it works and Privacy & Architecture.
Use Cases
What you build with Nexion
Gated features & crypto products
Wrap sensitive actions—first trade, high-risk product, mature content, internal tools—in policy checks. You define the rules, Nexion and the wallet enforce them.
Shared verification across apps
Reuse the same credential and policies across brands, regions, and chains. Users don't re-upload IDs for every app; your systems get consistent, auditable decisions.
Fundamentals
Core concepts
Policies
Policies describe what needs to be true for a user to proceed. They can include age, region, eligibility, or product-specific rules.
Example: age and residency policy
{
"id": "age18_eu_media",
"description": "18+ and in allowed EU countries",
"expression": "age >= 18 && residency in ['FR','DE','ES','IT']"
}Verifiers & receipts
A verifier is your app, service, or protocol calling Nexion. For each check, you receive:
- A Pass/Fail decision
- A signed policy receipt you can write into your logs
Simplified response
{
"policy_id": "age18_eu_media",
"decision": "pass",
"receipt": {
"issued_at": "2025-11-16T14:32:18Z",
"expires_at": "2025-11-16T14:37:18Z",
"jws": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9..."
}
}Integration
SDKs & APIs
Nexion is exposed as a set of HTTP APIs and client SDKs you can use from web, mobile, backend, and crypto services.
Client side
- Wallet integration for web and mobile apps
- Helpers to trigger issuance, request a policy proof, and handle wallet UX
- Built around standards like W3C Verifiable Credentials 2.0 and OID4VP
Server side
- APIs for registering verifiers and policies
- Endpoints to validate wallet presentations and record decisions
- Libraries and examples for common backend stacks
You can start with a simple "policy check" call and grow into more advanced integrations as needed.
Integration Patterns
Typical integration flows
Web or mobile app sign-up
- 1User signs up with your existing flow
- 2When they hit a gated route, you initiate wallet issuance via the client SDK
- 3The wallet completes eKYC and stores a credential
- 4Your backend calls Nexion with policy_id and the wallet presentation
- 5You enforce the Pass/Fail decision and store the policy receipt with your auth logs
Crypto product or protocol
- 1User connects their wallet or starts account creation
- 2You trigger Nexion wallet issuance (if they don't have a credential yet)
- 3Before sensitive actions (first trade, derivatives, RWA access), you request a policy proof
- 4Your backend validates the response and associates the decision with the user or address
- 5Receipts are written into your risk, case management, or trading logs
Internal tools & admin consoles
- 1Employee authenticates via your IdP as usual
- 2For sensitive tools, you call Nexion with a policy like employment_status == "active"
- 3Wallet proves the policy; you gate access on the decision
- 4Receipts show who was eligible to access what and when
API Example
Sample verification request
At the HTTP level, a verification call looks like a familiar JSON API:
Request
POST /v1/verify
POST /v1/verify
Authorization: Bearer <verifier_api_key>
Content-Type: application/json
{
"policy_id": "age18_eu_media",
"verifier_id": "your-app",
"presentation": "<wallet_presentation_token>",
"context": {
"flow": "signup",
"feature": "mature_content"
}
}Response
200 OK
{
"decision": "pass",
"policy_id": "age18_eu_media",
"verifier_id": "your-app",
"receipt": {
"id": "rec_01HQZ…",
"issued_at": "2025-11-16T14:32:18Z",
"expires_at": "2025-11-16T14:37:18Z",
"jws": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9..."
}
}You can write the receipt object straight into your existing logging and analytics pipelines.
Configuration
Environments & keys
Sandbox
- Dedicated sandbox environment for development and testing
- Test wallets and test credentials so you can exercise flows without hitting live eKYC providers
- API keys and dashboards scoped to sandbox projects
Production
- Separate production environment with its own keys and configuration
- Per-verifier configuration for policies, callback URLs, and logging behaviour
- Guardrails for key rotation and access controls
The docs walk through generating keys, configuring verifiers, and promoting policies from sandbox to production.
Operations
Logging & observability
Policy receipts are designed to fit naturally into your logging and monitoring stack.
Receipts serialize as small JSON objects you can ship to your log pipeline
You can correlate verification events with auth, risk, trading, or application logs
Metrics and dashboards can be built around policies, decisions, and error rates
Common Questions
Developer FAQ
Do we have to change our identity provider?
Nexion provides its own identity wallet with eKYC and supports OID4VP for authentication. You can use Nexion as your identity layer, or integrate it with your existing flows.
Can we use Nexion for both web2 and web3 flows?
Yes. You can call Nexion from traditional web and mobile apps, and from services that sit behind crypto wallets. The wallet-based model and policy receipts are the same; how you bind decisions to users or addresses is up to your architecture.
What happens if verification is unavailable?
You control how your product behaves when a policy check cannot be completed. Many teams choose to fail closed for high-risk flows and fail gracefully for low-risk ones.
How do we test without real IDs?
The sandbox environment includes test wallets and flows that simulate issuance and policy checks. You can build and test integrations without real documents or live eKYC traffic, and switch to production when you're ready.
How big are policy receipts and how long should we keep them?
Receipts are intentionally small JSON objects, much lighter than ID documents or full profiles. Retention is a policy decision for your legal and risk teams, but Nexion's model is designed so you can keep receipts for as long as you need evidence, without turning logs into an ID store.
Ready to see real requests and responses? Get in touch to schedule a technical walkthrough.