Get started with the Alter SDK for Python to make authenticated API calls to any OAuth provider, manage connections, and initiate OAuth flows. The SDK supports OAuth tokens, API keys, and custom credentials, all retrieved and injected automatically.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.
Installation
Requires Python 3.11 or higher.- pip
- Poetry
- pip
- Poetry
- pip
- Poetry
Basic Setup
The fastest way to get started:connect() opens a browser, the user authorizes, and the SDK returns a grant to use immediately:
Key Principle: Zero Token Exposure - You never see or handle OAuth tokens. The SDK retrieves them from Alter Vault and injects them automatically. All SDK-to-backend communication is cryptographically secured for integrity, authenticity, and replay protection.
Configuration
CallerType.SERVICE for backend infrastructure callers that should not appear in the Developer Portal Agents tab.
Audit logging is always enabled — every token retrieval and API call is automatically logged for compliance and security. The SDK automatically includes the HTTP method and target URL in the audit trail for each token request.
Connecting an Identity Provider
If the application uses an external IDP (Okta, Entra ID, Auth0, Clerk, Keycloak, or any OIDC issuer), wire it up to the SDK so every request is scoped to the signed-in end user. This is required forprovider= lookups (identity-based grant resolution) and powers group-based policies and instant deprovisioning.
One-time setup (Developer Portal): configure the app’s IDP on the Identity page — paste the OIDC issuer URL, click Discover, then save. Alter Vault auto-detects the IDP type and claim mappings. Each app can have only one IDP at a time; switching providers requires removing the current IDP configuration and then adding the replacement. See the IDP Setup Guide for per-provider steps.
Per-request wiring (SDK): pass a user_token_getter that returns the end user’s IDP-issued JWT. The SDK attaches it to every token request so the backend can resolve the user from the JWT claims.
Two resolution modes — pass
grant_id= when the caller already knows the exact grant, or pass provider= with an active end-user token source so the backend can resolve the grant from the JWT’s sub claim. The token source can come from constructor user_token_getter or from a token cached via vault.authenticate().vault.authenticate() to open a browser-based OIDC login through the IDP and receive the user profile. The SDK caches the resulting token internally and installs it as the active token source for that AlterVault instance. If constructor user_token_getter was set earlier, vault.authenticate() overrides it for subsequent provider= requests. Configure the IDP’s wallet/SDK client credentials in the Developer Portal first.
Connecting Without an IDP
The SDK does not require an identity provider. WhenAlterVault is constructed without a user_token_getter, every Connect session it produces creates a system-principal grant — bound to the app, not to any end user, and addressed by grant_id. This is the path for server-to-server jobs, CLI tools, fixture provisioning, and any environment where there is no signed-in user.
grant_id. A runnable example covering custom managed secrets, AWS, Cloudflare, and non-IDP OAuth lives at examples/system-principal-sandbox/.
Quick Error Handling
Revoking a Grant
Permanently revoke a grant when it’s no longer needed. Tokens are deleted from Vault and the grant status is set torevoked. The user must re-authorize via Alter Connect to restore access.
revoke_grant() raises GrantNotFoundError if the grant does not exist or is already revoked.
When the AlterVault instance has user_token_getter configured (including the AlterFastAPI dependency), revoke_grant() targets a grant owned by the authenticated caller — passing a grant_id that belongs to someone else raises GrantNotFoundError. See Scoping grant operations to the authenticated user in the overview.
Provisioning Managed-Secret Grants
create_managed_secret_grant() ties a managed secret to a specific principal (user, IDP group, or system). Use it when an admin or backend job needs to provision access without sending the end user through Alter Connect.
Principal is a discriminated union (type field is the discriminator). label is required on UserPrincipal and GroupPrincipal (rendered in the wallet) and optional on SystemPrincipal. The backend resolves and persists the principal: UserPrincipal validates the JWT and binds the grant to the resolved app user; GroupPrincipal upserts the IDP group; SystemPrincipal records a headless grant — anyone with the grant id and a valid signature for the app can retrieve the credential, so use only for backend flows with no caller user.
Next Steps
SDK Overview
Core concepts, complete examples, caller tracking, and error handling
FastMCP Integration
Build MCP tools with automatic OAuth credential injection
LangChain Integration
Build LangChain/LangGraph tools with automatic audit context
Quickstart Guide
Full integration walkthrough with frontend + backend