Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.alterauth.com/llms.txt

Use this file to discover all available pages before exploring further.

Alter Vault is the credential and authorization layer for apps and AI agents that call third-party APIs on behalf of users. An integration that needs to call Gmail, Slack, GitHub, Stripe, or any of 100+ other services normally means storing OAuth tokens securely, refreshing them, scoping them per user, logging every access for audit, and revoking them on demand. Alter does all of that. Application code becomes:
response = await vault.request("GET", url, grant_id=...)
No tokens in the application database. No tokens in application memory. No refresh logic. No audit plumbing.

The three things to work with

OAuth grants

For credentials that end users authorize — Gmail, Slack, GitHub. One grant per user per provider. Created when the user clicks “Connect Google.”

Managed secrets

For credentials the developer owns — API keys, service-account tokens, Stripe keys. Stored in the developer portal, used by the backend or by agents.

Agents

For workloads that need their own identity, key, and audit trail — chat agents, MCP servers, background jobs. Optional; only when one app key isn’t enough.

How to choose

QuestionAnswer
Is the credential something a user authorizes for themselves?OAuth grant
Is the credential something the developer provisioned?Managed secret
Are multiple distinct workloads running, each needing its own audit trail?Agents (in addition to one of the above)
All three can be mixed in one app.

How a request flows

app code              Alter SDK                Alter backend            Provider (e.g. Slack)
   │                       │                         │                          │
   │── vault.request() ───▶│                         │                          │
   │                       │── signed call ─────────▶│                          │
   │                       │                         │── inject token ─────────▶│
   │                       │                         │◀── response ─────────────│
   │                       │◀── response ────────────│                          │
   │◀── response ──────────│                         │                          │
The token never leaves the backend. The SDK only ever holds a short-lived HMAC key for signing — derived once at construction, discarded after use.

What’s no longer required to build

  • Token storage (encrypted at rest in a dedicated vault, never in the application DB)
  • Token refresh (handled per-provider, automatically)
  • Per-user scoping (grants are bound to principals; the SDK resolves them)
  • Audit logging (every call writes a row with caller, principal, provider, status)
  • Revocation UX (end users get Alter Wallet for free)
  • Policy enforcement (Cerbos-backed rules on every retrieval)

Where to go next

First 5 Minutes

Hands-on: post a Slack message from app code in under five minutes.

Principals and grants

The vocabulary the rest of these docs assume.