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.
For API-first and AI-native teams
AuthPI gives API-first and AI-native teams one identity system for users, organizations, services, and agents. Manage multi-tenancy, scoped credentials, agent access, and event-driven webhooks through a single API.
org_0kfz3m8q1w5e9r2t6y4u7i3o5 organization created inv_8d2f0kfz3m8q1w5e9r2t6y4u7 member invited key_7f3a9c2d4e5f67890123456789abcdef org-scoped key issued agt_7c1de2f3a4b5c6d7e8f9a0b1c2d3e4f5 AI agent identity created evt_01J5K8M9N2 delivered to your webhook How the model works
Users belong to organizations, services authenticate with scoped credentials, and AI agents get their own identities instead of borrowing user accounts or sharing service keys. Every identity action becomes an auditable event. AuthPI keeps this in one model, not a set of disconnected services you stitch together.
Managed through the API
Use the Core API to provision customers, mint organization keys, and give agents their own credentials. At runtime, your products use OAuth/OIDC endpoints; downstream systems follow changes from events and webhooks.
Create organizations, invitations, API keys, webhooks, clients, and agents through the Core API.
User apps, M2M clients, and agents authenticate against issuer runtime endpoints with OAuth 2.0 and OIDC.
Events cover mutations across the system, and webhooks deliver the changes your integration subscribes to.
OpenAPI-backed TypeScript and Python Admin SDKs keep examples close to the API shape.
import { 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!);
// Provision the customer model your product already knows about.
const org = await iss.organizations.create({ name: "Acme", org_type: "business" });
await iss.organization(org.id).invitations.create({
email_invited: "amir@acme.com",
scopes: ["member"],
});
const key = await iss.organization(org.id).apiKeys.create({
name: "Billing sync",
type: "api_key",
restrictions: { scopes: ["issuers.users:read", "events:read"] },
});
const agent = await iss.agents.create({
name: "Support triage agent",
scopes: ["tickets:read", "tickets:triage"],
});
const verifier = await iss.agent(agent.id).verifiers.create({
type: "secret",
name: "primary",
});
// The agent uses standard client_credentials at runtime.
// Mutations are available through the events API and subscribed webhooks. 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)
# Provision the customer model your product already knows about.
org = await iss.organizations.create({"name": "Acme", "org_type": "business"})
await iss.organization(org.id).invitations.create({
"email_invited": "amir@acme.com",
"scopes": ["member"],
})
key = await iss.organization(org.id).api_keys.create({
"name": "Billing sync",
"type": "api_key",
"restrictions": {"scopes": ["issuers.users:read", "events:read"]},
})
agent = await iss.agents.create({
"name": "Support triage agent",
"scopes": ["tickets:read", "tickets:triage"],
})
verifier = await iss.agent(agent.id).verifiers.create({
"type": "secret",
"name": "primary",
})
# The agent uses standard client_credentials at runtime.
# Mutations are available through the events API and subscribed webhooks.
Real @authpi/admin · authpi-admin calls generated from the Core API schema.
Core primitives
AuthPI models users, organizations, services, and AI agents as API-managed primitives. Each one is scoped, observable, and flows through the same event pipeline.
usr_ Users, sessions, verifiers, MFA, passkeys, and a branded portal for profile and credential management.
i_ / org_ Issuers, organizations, memberships, domains, and SSO model your customers without bolting tenant logic onto user auth.
agt_ First-class agt_ identities for AI agents and bots, with their own scopes, verifiers, organization memberships, and audit trail.
key_ / c_ Org API keys for managing AuthPI resources, and OAuth client_credentials for services calling your own APIs.
ptk_ Personal access tokens let users connect CLI tools, scripts, and automations while you define the scopes they can request.
std OAuth 2.0, OpenID Connect, JWTs, JWKS, PKCE, WebAuthn, and OpenAPI specs where your APIs expect them.
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.
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.
Read how the global identity mesh worksAuthPI does all of it. one issuer, worldwide.
Sign-in options
Any combination. Social for consumers, enterprise SSO for B2B, passkeys for the security-conscious.
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.
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.
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.
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 killed and every refresh token
for the user 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.
Who it is for
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.
Standards underneath
Standard protocols mean your existing tools just work. Switch providers anytime and your integration code stays the same.
Attach JSON to any resource: users, organizations, sessions. Store your Stripe ID, Salesforce ID, whatever you need.
Full API reference you can import into Postman, Insomnia, or your code generator of choice.
Every request and response fully typed. Catch integration bugs at compile time, not runtime.
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.