Eligibility Verification API

What is an Eligibility Verification API?

An eligibility verification API answers one question: is this subject eligible for this rule? The caller sends a subject identifier (e.g. user_id, device_id, or an opaque reference) and a rule name (e.g. payment_eligibility, benefit_entitlement, access_grant). The API consults external data sources in real time, applies the rule logic, and returns a single boolean. No session, no identity store, no PII written to disk.

Traditional verification often involves identity providers (IdPs), OAuth flows, or SAML assertions that issue tokens and maintain session state. An eligibility verification API is different: it is a decision endpoint. You get a yes or no. That reduces compliance surface (no token storage, no user profiles), simplifies integration (one request, one response), and keeps the system stateless so it scales and audits cleanly.

Stateless Decision Infrastructure

AffixIO runs as stateless decision infrastructure. Each request is independent; the API does not retain state between calls. The pipeline is: receive subject + rule → resolve subject against configured data sources (your systems or approved third parties) → evaluate rule → return eligible: true | false. No database of users, no cache of decisions for replay. The decision is computed at request time from live data.

Statelessness matters for compliance and resilience. There is no central store of PII to breach. There is no session to hijack. Failures are request-scoped. For fintech and regulated environments, this aligns with data minimization and zero-data designs.

Privacy-Preserving Verification

Privacy-preserving verification means the API does not need to see or store raw personal data to return a decision. AffixIO can integrate with data sources that expose only the minimal attributes required for the rule (e.g. balance threshold, membership flag). The API returns only the binary outcome. No PII is logged or persisted by the eligibility layer. This supports GDPR, CCPA, and sector rules (e.g. financial, health) where storing unnecessary PII creates liability.

Why not store the result?

Caching eligibility results would create a new data store—who was eligible when. That store becomes subject to retention policies, access controls, and breach risk. By not storing, the eligibility verification API avoids that entirely. The caller can cache the result in their own boundary under their own policies if needed.

Example API Flow

The eligibility verification API exposes a single verification endpoint. You send a subject and a rule; you receive eligible.

{
  "subject": "user_id",
  "rule": "payment_eligibility"
}

{
  "eligible": true
}

The subject is an opaque identifier your system uses to look up the entity (person, device, or account). The rule is a named policy (e.g. payment_eligibility, benefit_eligibility) configured in your AffixIO tenant. The response is JSON with a single boolean. Authentication uses API keys or mTLS; see the API docs at api.affix-io.com.

Use Cases: Payments, Benefits, Compliance

The same eligibility verification API pattern applies across domains.

Payments

Before initiating a payment or allowing a withdrawal, call the API with the payer subject and a rule such as payment_eligibility. The rule might encode balance checks, velocity limits, or sanctions screening. You get a yes/no; no card or account details need to pass through the verification layer. Useful for offline payment verification and terminal flows when combined with offline-capable circuits.

Benefits and entitlements

Determine whether a person is eligible for a benefit, subsidy, or entitlement without pulling full profile data into your app. Subject + rule returns eligible. Reduces data movement and keeps eligibility logic centralized and auditable. See benefit eligibility for more.

Compliance and access

Use rules for access control, KYC/AML checks, or regulatory gates. The API returns whether the subject passes the rule; your system grants or denies access. No need to store verification results in a separate database—each check is stateless.

Why Stateless Verification Matters

Stateless verification reduces attack surface and compliance scope. There is no eligibility database to steal. There is no session store to abuse. Audits can focus on rule configuration and access to the API and data sources, not on a new silo of PII. For enterprises and fintechs, that translates to lower PCI scope, clearer data residency, and simpler privacy documentation. AffixIO positions as stateless eligibility and authorization infrastructure for this reason.

Developer Integration Example

Integrate the eligibility verification API from any environment that can send HTTPS POST requests. The API base URL is https://api.affix-io.com; the verify endpoint is POST /v1/verify with identifier and circuit_id (see openapi.json). Example with curl:

curl -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"}'

Replace YOUR_API_KEY with your key. Request body: identifier (pseudonymised or hashed reference) and circuit_id from GET https://api.affix-io.com/v1/circuits. Response is JSON with eligible (boolean), data_retained: null, and optional token, latency_ms. For SDKs and full spec, see Identify via API and openapi.json. For agent-driven flows, use the same verify semantics behind an agent authorization infrastructure layer.