Site Owner vs Agent
AIdenID primarily serves site owners who need agent-traffic clearance. Agent builders and human inbox users interact with supporting identity and inbox surfaces that feed evidence and issuer context into that clearance model.
One clearance buyer, supporting audiences
The core AIdenID buyer is the site that must decide whether an agent-attributable request gets through. Supporting APIs let agent issuers create scoped identities, QA teams gather inbox evidence, and humans use a smaller disposable-inbox product. The infrastructure is shared, but the decision layer is the center.
Authentication
Site owners, agents, and humans authenticate differently based on their interaction model:
- Site owners — Use control-plane API keys, dashboard sessions, and verifier configuration to register targets, policies, webhooks, and exports.
- Agents (paid) — Use API keys via the
Authorization: Bearerheader, combined withX-Org-IdandX-Project-Idheaders to scope requests to the correct project. - Agents (free tier) — No authentication required. Access is IP-keyed with ephemeral tokens. One active identity per IP.
- Humans — Use magic-link email authentication (passwordless). Sessions are cookie-based with automatic refresh. No passwords to manage.
Identity management
Site owners manage protected targets, route policy, and revocation state. Agents create and manage supporting identities via the REST API, often provisioning identities in bulk for authorized workflows. Humans use the web inbox UI to create and manage a smaller number of identities.
Evidence delivery
Site owners receive decision evidence; supporting identity users may also receive inbox extraction evidence:
- Site owners — Receive decision streams, OCSF exports, audit roots, revocation events, and demo proof packs.
- Agents — Receive extracted OTPs via API polling, webhooks, or SSE streams. Fully programmatic, no human in the loop.
- Humans — See OTPs in their web inbox with real-time SSE updates. Optionally receive email notifications forwarded to their personal email address.
Lifecycle
Identity lifecycle patterns differ between the two audiences:
- Agent identities — Ephemeral tools with TTLs ranging from 24 hours to 365 days. Created and destroyed automatically as part of agent workflows. Squashed programmatically when the flow completes.
- Human identities — Tend to live longer (7 to 30 days) and are managed manually through the inbox UI. Users extend or delete identities as needed.
See Identity Lifecycle for a deep dive into states and transitions.
Rate limits
Different tiers have different rate limits to match their usage patterns:
| Tier | Requests/min |
|---|---|
| Free agent (no auth) | 10 |
| Free human trial | 30 |
| Starter | 60 |
| Growth | 300 |
| Pro | 1,000 |
See Plans & Limits for full details including burst allowances.
Use cases
| Site-owner use cases | Supporting identity/inbox use cases |
|---|---|
| Agent clearance for checkout, support, and account routes | Signup testing and QA automation |
| Observe-to-enforce rollout with counterfactual reporting | Scoped issuer identities for delegated agents |
| Revocation drills and audit evidence for security teams | Disposable email for privacy or one-time verifications |
| Pricing, queueing, or sandboxing unknown automation | Authorized auth-flow monitoring |
Under the hood, clearance decisions, identities, email ingress, extraction, webhooks, and lifecycle state share the same audit-first operating model. The difference is whether the user is making a route decision or producing supporting issuer/inbox evidence.