Calling AuthPI?
key_ Org API keys
Use for the Core API
Backend services, CI jobs, and scripts manage AuthPI resources such as users, issuers, clients, webhooks, and organizations.
AuthPI gives API-first teams a single identity model for users, organizations, services, and AI agents. Multi-tenancy, scoped credentials, M2M auth, short-lived agent tokens, webhooks, and audit events are all built in.
How the model works
Users belong to organizations, services authenticate with scoped credentials, and AI agents get identities of their own. In AuthPI these are one model with one event stream, and none of them is an add-on you bolt on later.
Included with every issuer
Agent identity
When agents call your API as borrowed users or shared keys, you can't scope them, revoke them, or audit them. AuthPI makes the agent a first-class identity next to your users and services.
Agent starts a work cycle
support-triage needs tickets:read
Mints a scoped token
POST /i_4r8w2k9m5x1p7q/token · client_credentials
{ "expires_in": 300, "scope": "tickets:read" } Calls your API
GET /tickets · Authorization: Bearer …
200 OK · JWT verified against your issuer's JWKS Expires five minutes later
expiredno refresh token exists · next cycle mints fresh
Your customer model
Organizations are the boundary for B2B customers, workspaces, departments, and teams. They carry members, agents, scopes, SSO configuration, invitations, metadata, and lifecycle events in one API model.
Token context
When a user or agent acts inside a customer tenant, AuthPI issues organization context with the token. Your API authorizes against the org, member, scopes, and membership status it receives.
Membership changes are reflected on the next login, refresh, or userinfo call; existing access tokens remain bounded by their configured lifetime.
A stable org_ ID with business type, contact data, custom fields, metadata, member limits, and status.
Users and agents join organizations with their own scopes, titles, metadata, and active or suspended status.
Invitation flows, verified SSO domains, SSO-only enforcement, MFA policy, and default member scopes live with the organization.
Suspend to remove org claims from newly issued tokens; delete to cascade memberships, invitations, SSO config, and org API keys.
Sign-in, on open standards
Social for consumers, enterprise SSO for B2B, passkeys for the security-conscious: any combination. Each method rides an open protocol, so your existing tools work and switching providers never strands your integration code.
Google, GitHub, Microsoft, Apple. Users sign in with accounts they already have.
Connect Okta, Azure AD, or any OIDC provider. Your enterprise customers expect it.
No passwords, no phishing. Syncs across all their devices, backed by the platform authenticator.
One click in their inbox, they're signed in. Simple, secure, no password to forget.
When you need them. Industry-leading hashing, breach detection, strength requirements.
TOTP codes from any authenticator app, plus backup codes for recovery.
Access for code
Pick by destination first: org API keys manage AuthPI, M2M clients mint OAuth tokens for your own APIs, and personal tokens let users run scripts as themselves.
Calling AuthPI?
key_ Use for the Core API
Backend services, CI jobs, and scripts manage AuthPI resources such as users, issuers, clients, webhooks, and organizations.
Calling your APIs?
c_ Use for service-to-service auth
One of your systems exchanges client credentials for a standard OAuth access token that your APIs can verify locally.
Acting as a user?
ptk_ Use for user-owned automation
CLI tools, local scripts, and integrations act as a specific user without exposing the user's primary credentials.
These credentials compose in production: a backend can hold an org API key to provision AuthPI resources and an M2M client to call internal APIs, while users keep personal tokens for their own scripts.
Session protection
Every session comes with rotating refresh tokens, reuse detection, device tracking, and configurable timeouts. When something looks wrong, AuthPI responds on its own and tells you through an event. None of it needs code on your side.
Refresh tokens rotate on every use. If one is presented twice, the session is killed immediately: a stolen token is a dead token.
Each session records the device it runs on, so unusual access stands out before it becomes an incident.
Idle timeouts, absolute lifetimes, or activity-based extension. Your policy, enforced automatically by the issuer.
One API call logs a user out everywhere. One call revokes an organization's sessions. Incident response without a runbook.
Reuse detected
An already-rotated refresh token is presented a second time.
Session terminated
s_01j5k8m9n2 is revoked and every token issued
to it is invalidated. The attacker holds a dead token.
EVENT session.compromised
Delivered to your webhook with the session and user in the payload, ready for your incident tooling.
The identity graph
Everything lives inside an issuer: one user pool, one token endpoint, your domain. Organizations partition it per customer, and each kind of actor gets credentials shaped to how it behaves: humans hold sessions, services hold longer-lived tokens, agents live five minutes at a time.
org_ Your customer's tenant: members, groups, invitations, and org-scoped API keys (key_) with scope and IP-allowlist restrictions.
usr_ Sign in and stay signed in.
c_ Deterministic code calling your APIs.
agt_ Autonomous, so trusted five minutes at a time.
Every actor's state changes, lifecycle transitions, and security signals are persisted as events. Webhooks subscribe to exact event types and keep delivery records for retries and debugging.
API, SDKs, and docs
Everything AuthPI does is reachable through the API, wrapped in typed SDKs for TypeScript and Python, and documented for you and for the coding agents working alongside you.
Full CRUD for every resource in the model, defined in OpenAPI 3.1. Cursor pagination, idempotency keys, and conditional requests throughout.
Browse the API reference@authpi/admin and @authpi/idp for TypeScript, authpi-admin and authpi-idp for Python. Typed end to end, generated from the same spec.
Pick your SDKNext.js, SvelteKit, Hono, Workers, agents, and more, plus concepts and reference pages. llms.txt included, so coding agents read the same docs you do.
Open the docsimport { AuthPIAdmin } from "@authpi/admin";
const admin = new AuthPIAdmin({
apiKey: { id: process.env.AUTHPI_KEY_ID!, secret: process.env.AUTHPI_KEY_SECRET! },
accountId: process.env.ACCOUNT_ID!,
});
const iss = admin.issuer(process.env.ISSUER_ID!);
// A customer and an agent, three calls.
const org = await iss.organizations.create({ name: "Acme", org_type: "business" });
const agent = await iss.agents.create({
name: "Support triage agent",
scopes: ["tickets:read", "tickets:triage"],
});
await iss.agent(agent.id).verifiers.create({ type: "secret", name: "primary" });
// The agent authenticates with standard client_credentials at runtime. from authpi_admin import AuthPIAdmin
async with AuthPIAdmin(api_key=(KEY_ID, KEY_SECRET), account_id=ACCOUNT_ID) as admin:
iss = admin.issuer(ISSUER_ID)
# A customer and an agent, three calls.
org = await iss.organizations.create({"name": "Acme", "org_type": "business"})
agent = await iss.agents.create({
"name": "Support triage agent",
"scopes": ["tickets:read", "tickets:triage"],
})
await iss.agent(agent.id).verifiers.create({"type": "secret", "name": "primary"})
# The agent authenticates with standard client_credentials at runtime.
Real @authpi/admin · authpi-admin calls generated from the Core API schema.
Events and webhooks
AuthPI emits events for users, sessions, organizations, clients, API keys, agents, accounts, and webhooks. Active subscriptions receive matching account events as CloudEvents payloads, with delivery attempts stored for debugging and audit.
Runtime and data
Auth for users, organizations, services, and agents answers from the location nearest each request. OAuth, token issuance, JWKS. You ship to one place, which is nowhere in particular.
AuthPI does all of it. One issuer, worldwide.
Read how the global identity mesh workssignup · lagos (LOS) → weur · eu jurisdiction, enforced
Use cases
From a single API to a multi-party platform, the same primitives model people, services, and AI agents.
Your product is an API whose customers are companies. Organizations, memberships, and scoped keys are built-in primitives, so you add multi-tenancy in days, not quarters.
You host other people's services and integrations. Dedicated identity per tenant, machine-to-machine auth, and per-party event routing with full isolation.
People and agents both call your API. Give each AI agent its own identity, scopes, organization membership, and audit trail instead of borrowing a user account or sharing an API key.
Get started
Create an account, grab your API keys, and model users, organizations, services, and agents in one system. No credit card, no sales calls.