Verified API Access for AI Model Providers: A Risk-Tiered Architecture

The hard part of putting identity verification in front of an AI API is not the verification. It is deciding who never sees one.

Get that wrong in the strict direction and you have taxed every developer who wanted to try your model on a Saturday afternoon — the exact population you spent your growth budget acquiring. Get it wrong in the permissive direction and you have built a control that the only people who matter route around.

This is an architecture problem, and it has a reasonably well-defined answer: verify on risk, not on population. This guide covers how to tier access, what should trigger a check at each tier, which Didit endpoints implement each one, and what it costs.

Key takeaways

• Verification belongs at access transitions — quota increases, credit grants, new key issuance, tier upgrades — not at signup.
• Four tiers work for most platforms: anonymous / free, paid self-serve, high-quota or high-credit, and organisation or research.
• Cost scales with the fraction of access you actually gate: $0.03 for IP and device analysis, $0.33 for the full identity bundle, $0.10 for biometric re-authentication, from $2.00 for business verification.
• Reusable KYC is free — a developer already verified on the Didit network clears a check without repeating it.
• Behavioral alerts from your own traffic layer make the best triggers. Identity is the response, not the detector.
• The whole thing is a workflow, not a wall. Build it in the Workflow Orchestrator (free) and change policy without shipping code.

The design principle

Every verification decision trades two costs: the friction you impose on legitimate users and the access you grant to an unverified one. A flat policy optimises neither — it takes the maximum of both.

The alternative is to make verification a function of what the account is asking for. A developer pulling 200 requests against a public model with a $5 spend cap is not a meaningful extraction risk regardless of who they are. A newly created account requesting a 50× quota increase, paying with an instrument that has appeared on nine other accounts this week, from a device your system has seen before under a different owner, is a different proposition entirely — and it is worth thirty-three cents to know who they are.

Anthropic's own published mitigations point in exactly this direction. Alongside detection classifiers and behavioral fingerprinting, the company lists "strengthened verification for educational and startup accounts" — verification targeted at specific access categories rather than applied to the whole developer base. That is the shape.

The four tiers

Tier 0 — anonymous / free

Who: anyone who signed up to try the model.

Verify: nothing. Email verification at most.

Why: the population is enormous, the per-account value to an attacker is capped by your rate limits, and any friction here is a straight growth tax.

Cost: $0.03 for email verification, or zero.

The control at this tier is the rate limit, not identity.

Tier 1 — paid self-serve

Who: anyone who has attached a payment method and is spending.

Verify: passive signals only — IP and device analysis at $0.03.

Why: you want the linking substrate without the friction. Collecting device and network signals at this tier means that when an account escalates later, or when your traffic layer flags it, you already have the correlation data. Retrofitting that after the fact is impossible.

Cost: $0.03 per account, once.

This is the highest-leverage tier in the whole design and the one most often skipped. The codes you are buying — DUPLICATED_DEVICE_FINGERPRINT, DEVICE_RECOVERED_HIGH_CONFIDENCE, DUPLICATED_IP_ADDRESS, AUTOMATION_FRAMEWORK_DETECTED — are what make every later investigation possible.

Tier 2 — high quota / high credit / capability-gated

Who: accounts requesting elevated rate limits, large credit grants, or access to capability tiers you treat as sensitive.

Verify: full identity — $0.33 for ID document, passive liveness, face match and IP analysis.

Why: this is where extraction economics start to work for an attacker, and where binding the account to an attributable person changes their calculus.

Cost: $0.33 per verified account. The first 500 KYC verifications each month are free.

Face Search 1:N runs automatically during the liveness step here, so the tier that matters most is also the tier where you get duplicate detection for free.

Tier 3 — organisation, enterprise, research and educational

Who: companies, labs and institutions requesting organisation-level access, custom terms, or research programme entry.

Verify: business verification from $2.00 — registry lookup, ultimate beneficial owners, officers, entity screening, plus a linked identity check for each beneficial owner.

Why: "is this a real company, and who actually controls it" is a different question from "is this a real person," and at this tier it is the right one. It is also the tier where a shell entity buys the most leverage per unit of effort.

Cost: from $2.00 per company; $0.20 per document; $0.20 for entity screening.

What should trigger a check

Tiers describe who. Triggers describe when. The best trigger designs fire on transitions and on evidence, not on the calendar.

Access transitions. Quota increase, credit grant, new API key issuance, tier upgrade, first payout, addition of a team member with elevated scope.

Behavioral alerts from your own traffic layer. This is the important one. Your semantic detection — whether that is an in-house classifier or something in the shape of the maximum-mean-discrepancy approach in arXiv 2606.05725 — produces a signal that identity infrastructure cannot. Feed it in as a trigger. Identity is the response to that alert, not a substitute for it.

Linking signals from a prior verification. An account whose device already carries DEVICE_RECOVERED_HIGH_CONFIDENCE, or whose face matched an existing verified user, has earned a step-up regardless of what it is asking for.

Policy geography. IP_LOCATION_NOT_ALLOWED and COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP cover jurisdictional restrictions where you have them.

Never on a timer alone. Re-verifying everyone quarterly generates cost and friction proportional to your user base and inversely proportional to nothing.

And to be explicit about the boundary: none of this prevents model extraction. A verified-access architecture reduces anonymity, links accounts to a single actor, and makes regenerated accounts expensive — it does not inspect prompts and cannot tell you that a request stream looks like distillation. Model-level output controls and semantic traffic detection are separate layers that stay inside your own stack. This architecture makes those layers more actionable; it does not replace either one.

Implementation

One session endpoint, one workflow per policy

Every verification tier is a session against the same endpoint. The workflow determines which checks run.

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_TIER2_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/verification/complete"
  }'

vendor_data is your own account identifier. Keep it stable across every session for that account — it is what lets you correlate a later biometric re-authentication back to the original verification, and it is what appears in Face Search matches so you can map results straight onto account IDs.

The response carries a session URL you redirect the developer to, or you embed the flow directly with the web, iOS, Android, React Native or Flutter SDKs — all free.

Decisions arrive by webhook

Subscribe to session.status.updated and read the decision:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

The decision carries the per-feature results and the warning codes. Route on the warnings rather than on the top-level status alone — a session can be approved and still carry DUPLICATED_DEVICE_FINGERPRINT, which is a signal you want.

Compose the tiers in the Workflow Orchestrator

The Workflow Orchestrator is free and visual. Build one workflow per tier, with conditional branching so a single workflow can escalate — start with IP and device analysis, branch to full document verification when a warning fires, branch to business verification when the account declares an organisation. Changing the policy is a change in the console, not a deploy.

Keep the trusted path fast

Two mechanisms matter here.

Reusable KYC is free. A developer who has already completed verification elsewhere on the Didit network can clear your check without redoing the document and selfie flow. For a developer audience — which skews toward people who have verified somewhere before — this materially reduces the felt friction.

Allowlists. The Lists API supports allowlists across all 12 entry types. Known-good devices, IP ranges, business entities and users can be allowlisted so they never see a step-up. IP_ADDRESS_IN_ALLOWLIST and DEVICE_FINGERPRINT_IN_ALLOWLIST are emitted when a match occurs, so you can confirm the exemption applied.

What this costs in practice

The point of tiering is that the expensive checks apply to a small fraction of accounts. A platform with 100,000 registered developers might see something like:

Tier	Share of accounts	Check	Unit cost
Free	85%	none, or email at $0.03	$0 – $0.03
Paid self-serve	12%	IP + device	$0.03
High quota / credit	2.5%	full identity bundle	$0.33
Organisation / research	0.5%	business verification	from $2.00

Every price above is published, pay-per-success, and has no minimum. You are billed on successful checks, so abandoned flows do not cost you. The first 500 KYC verifications each month are free.

The illustrative distribution is not a benchmark — your mix will differ. The structural point holds regardless: the tier that costs the most applies to the fewest accounts, and the tier that applies to the most accounts costs nothing.

Use cases

Frontier model providers gating quota escalation and research-programme entry while leaving the free tier untouched.

Inference and API aggregators who resell model access and inherit the abuse without owning the model-level controls — for them the access layer is often the only control they realistically have.

AI coding and agent products binding credit grants and trial extensions to a verified person, since credit farming and extraction share the same mechanics.

Cloud AI marketplaces verifying the selling entity and its beneficial owners before listing.

Frequently asked questions

Where exactly should the verification step sit in the flow?

At the moment of the access grant, not at signup. Let the developer sign up, read the docs, get a key, and make real calls. Ask for verification when they ask for something that carries risk. Verification at signup converts worst and protects least.

What happens to a developer who refuses to verify?

That is your policy, and the honest answer is that it should usually not be a ban. Keep them on the tier they qualify for without verification. Refusal is a signal, not a verdict — plenty of legitimate developers simply do not want to hand over a document for a hobby project, and they should be able to keep building at a tier where their access is not worth much to an attacker.

Can this run without redirecting the developer to a hosted page?

Yes. The web, iOS, Android, React Native and Flutter SDKs embed the flow in your own product, and White Label ($0.20) removes Didit branding entirely. All SDKs are free.

How do I avoid verifying the same person twice?

Use a stable vendor_data per account, and rely on Reusable KYC — free — so a developer verified elsewhere on the network does not repeat the flow. Face Search 1:N also tells you when a new verification matches an existing verified user, which is both a deduplication signal and an abuse signal depending on context.

Does Didit see our prompts or our traffic?

No. Didit sees the verification session — document, selfie, device and network signals for that session — and nothing about your API traffic. Semantic detection stays entirely inside your stack. The integration point is that your alert becomes a trigger for a verification step.

How long does the whole thing take for the developer?

The verification itself returns in under two seconds once the images are captured. End to end, a document-and-selfie flow is typically well under a minute, and Reusable KYC is faster still.

Ready to get started?

Build the tier structure once and adjust the thresholds forever after.

• Read the docs — Sessions API, IP & Device Analysis, Reusable KYC and the Lists API for allowlists.
• See the product — User Verification and Business Verification.
• Check the pricing — every module is publicly priced, no minimums.
• Start free — business.didit.me. Build the workflow, run 500 KYC verifications a month at no cost.