Verifications
Create sandbox verification requests with a purpose string, consent context, and idempotency key.
Use fixture data first, then move to production only after consent, logging, support, and DSR routes are reviewed.
curl -X POST https://sandbox.pramaan.online/v1/verify \
-H "Authorization: Bearer $PRAMAAN_SANDBOX_KEY" \
-H "Idempotency-Key: demo-fixture-001" \
-H "Content-Type: application/json" \
-d '{
"subject": {
"name": "Sandbox Worker",
"phone": "+910000000000"
},
"purpose": "household_help_verification_demo",
"checks": ["identity", "address"],
"fixture": "fixture_green_domestic_help"
}'Production behavior is current only where the page clearly marks it current.
Create sandbox verification requests with a purpose string, consent context, and idempotency key.
Model notice, data categories, channel, timestamp, language, retention, and withdrawal route.
Use signed event examples as integration guidance until production delivery behavior is confirmed.
Verify sample badge payloads and explain expiry, revocation, and public-key handling.
Route access, correction, erasure, grievance, nomination, and withdrawal requests.
Procurement-grade export remains roadmap unless enabled for a specific enterprise account.
Sandbox keys are for fixture payloads only. Production keys are issued only after purpose, consent, logging, DSR, and support routes are reviewed.
Never paste real API keys, Aadhaar, PAN, OTPs, raw documents, or private keys into examples, screenshots, tickets, or chat.
Start in sandbox with fixture data, then move to production only after purpose, consent copy, logging, DSR, and support routes are reviewed.