Online
Every verify hits live data. If the source encodes single-use (balance, one-time token, consumed flag), the second call returns No once consumption is visible.
Docs · For engineers
Technical architecture
Proof generation, double-spend detection, offline terminals, reconciliation, and security assumptions. Explore the flow below, then copy real API examples.
Request inAllow or DenySigned proof out
0PII at verifier
2Outcomes only
~43msTypical latency
PQCPost-quantum ready
Architecture overview
AffixIO is a stateless binary eligibility engine. The terminal or edge device sends an identifier and circuit_id; the API queries authoritative data sources in real time, applies circuit logic, and returns only Yes or No. No PII is stored. Offline deployments generate local proofs that reconcile when connectivity returns.
Terminal / edge
Sends a pseudonymised identifier and circuit_id. NFC, biometric, QR, or hashed references are supported. No raw PII needs to leave your channel if you hash client-side.
identifier + circuit_idDashed path when offline: local proof on device → reconcile on reconnect → double-spend checks at settlement.
Proof generation
Proofs are generated in two modes. Select a mode to see how it behaves.
The terminal sends POST /v1/verify with identifier and circuit_id. The API resolves against live data sources, runs circuit logic, and returns a signed binary result. The response is the proof: log it or pass it downstream without exposing PII. Structure is deterministic (signature + nonce + circuit binding).
When the API is unreachable, the terminal produces a local proof: a commitment to identifier, circuit, timestamp, and device context. Store the proof or digest; default to No if policy requires. On reconnect, submit proofs for reconciliation and double-spend detection.
POST /v1/verify
// Verify request (online or offline-capable)
POST /v1/verify
{
"identifier": "<opaque or hashed>",
"circuit_id": "<circuit>"
}
// Response: eligible + proof material (no PII)
Developer quickstart
Real endpoints from openapi.json. Toggle sandbox, switch tabs, and copy curl examples.
Discover available circuit_id values before calling verify.
List circuits
curl -s \
"https://api.affix-io.com/v1/circuits" \
-H "Authorization: Bearer <YOUR_API_KEY>" | jq '.circuits[0:3]'
# Example response (truncated)
{
"circuits": [
{ "id": "health-age-verification", "sector": "health" },
{ "id": "finance-kyc-verification", "sector": "finance" }
],
"total": <N>
}
Hash identifiers client-side. Response includes eligible and data_retained: null.
POST /verify
# echo -n "user-123@example.com" | sha256sum
curl -s -X POST \
"https://api.affix-io.com/v1/verify" \
-H "Authorization: Bearer <YOUR_API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"identifier": "3a7bd3e27785e7b7a6c0e7c1f4f3f6b8",
"circuit_id": "health-age-verification",
"metadata": { "timestamp": 1731000000, "source": "checkout-web" }
}'
{
"eligible": true,
"circuit_id": "health-age-verification",
"token": "<JWT_VERIFICATION_TOKEN>",
"latency_ms": 43,
"data_retained": null
}
Re-check a cached token without hitting the original data source.
GET /tokens/{id}/verify
curl -s \
"https://api.affix-io.com/v1/tokens/<JWT_VERIFICATION_TOKEN>/verify" \
-H "Authorization: Bearer <YOUR_API_KEY>"
{
"valid": true,
"eligible": true,
"circuit_id": "health-age-verification",
"issued_at": "2026-03-10T11:59:12Z",
"expires_at": "2026-03-10T12:00:00Z"
}
Double-spend detection
Double-spend is using the same entitlement more than once before the system enforces single use.
Offline + reconciliation
Proofs bind identifier, circuit, time window, and device id. On reconnect, replay uses deterministic ordering. Only the first valid proof wins; others reject for audit.
Terminal behaviour offline
When connectivity drops, behaviour is explicit and auditable.
No fail-open
Never assume eligibility. Use signed default No or wait for connectivity.
Local proofs
Store commitments per would-be verify call for reconciliation later.
Clear UX
Return verifiable no or pending. No silent failure.
No PII on device
Only proof digests kept, not raw identifiers.
Reconciliation when reconnecting
Click a step to see what happens at each stage. Reconciliation is idempotent after the first successful run.
Security assumptions
Explicit assumptions for engineering and risk review.
Data source authority
Eligibility is as trustworthy as the data sources you connect. AffixIO queries and applies circuit logic without altering source data. Compromised or stale sources produce matching results.
Circuit integrity
Circuits are versioned by circuit_id. Client tampering does not change API results; the API runs canonical logic. Offline proofs bind to the circuit for replay.
No PII storage
AffixIO does not store PII. Requests are processed in real time; logs and reconciliation use proof digests and outcomes, not raw identifiers.
Terminal and channel
HTTPS protects data in transit. Compromised terminals may forge local proofs; reconciliation still enforces eligibility and double-spend against authoritative sources.
Time and ordering
Offline reconciliation uses deterministic ordering (timestamp, sequence, device id). Loosely synchronized clocks or policy-defined acceptance windows handle skew.
Post-quantum (PQC) readiness
Long-lived proofs and audit artefacts can use quantum-resistant signing aligned with post-quantum cryptography planning. See government digital identity and investor materials for public PQC context.
Contact
Tell us your setup
Write to us about your setting. We answer with a practical wiring diagram for your team.