Providers

A provider is a third-party service Alter knows how to talk to. Alter ships with two kinds: OAuth providers (the end user authorizes access to their own account) and managed-secret providers (the operator pastes a long-lived credential into the portal).

An OAuth provider configuration is created once per app and provider. A managed-secret template can be used for multiple independently named secrets in the same app. In both cases, the resulting credential can back multiple grants — including multiple account-specific OAuth grants for one end user, or managed-secret grants for several bound principals.

OAuth providers

Used when the credential belongs to an end user. The user clicks a Connect button, completes the OAuth flow at the provider, and Alter stores the resulting tokens.

Examples: Google, Slack, GitHub, Notion, HubSpot, Stripe (Connect), Salesforce.

Configuration is a one-time step in the developer portal. The provider card shows Managed credentials available when Alter can supply the provider OAuth app; alter providers list-catalog exposes the same live capability in its MANAGED column and as managed_credentials_available in JSON. The list is discovered from the deployment rather than maintained as a hardcoded provider count.

Credentials managed by Alter

Choose the managed option for zero provider-console setup. Alter owns the OAuth app, consent branding, callback URLs, and provider quota. The option is not tied to an Alter-app environment: the legacy API/CLI value is shared_dev, but any Alter app may use a managed credential when the catalog reports it available.

Managed credentials are a good fit when Alter’s consent branding, approved scope set, shared quota, and production provider deployment meet the product’s needs. The portal and alter providers list-catalog show the exact managed_approved_scopes for Alter’s current OAuth client; the broader catalog is not evidence that the client may request every provider scope. The picker deliberately does not link to a provider console — it belongs to Alter, not to your organization.

Use your own OAuth app when you need any of these:

• your product’s name and logo on the provider consent screen;
• a scope that is not offered by the managed configuration;
• dedicated provider quota, provider analytics, or your own provider review;
• a provider sandbox, custom tenant, or another provider deployment; or
• control of the OAuth app’s lifecycle and incident response.

With your own OAuth app:

1. Register an OAuth client at the provider.
2. Add Alter’s redirect URI as an authorized callback.
3. Paste the client ID and secret into the portal.
4. Pick the default scope set the app needs.

Switching an existing configuration changes the OAuth client that future connections authorize. Existing provider tokens remain bound to the client that issued them, so Alter immediately marks every existing connection for reconnection and blocks its old token. Each user must complete fresh consent under the new OAuth client before that connection can be used again. Rotating the secret for the same custom client ID does not require user reconnection.

Browse the full list at OAuth providers.

Managed-secret providers

Used when the credential is owned by the operator — an API key, service-account token, or AWS access key. The operator pastes the credential once; the SDK injects it into outgoing calls the same way it injects an OAuth token.

Examples: Datadog API key, Stripe secret key, SendGrid, AWS, Cloudflare, Twilio.

Configuration is a one-time step:

1. Generate the credential at the provider.
2. Paste it into the portal under Managed Secrets.
3. Issue grants binding the credential to specific principals (users, groups, the system, or an agent).

Browse the full list at Managed secret providers.

Custom providers

For any OAuth provider not in the catalog, configure it through the Custom OAuth template — point Alter at the authorize / token / revoke URLs and Alter handles the rest. For any managed-secret provider not in the catalog, the Custom template supports arbitrary header names, injection formats (Bearer {token}, Token {token}, Key {token}), and multi-header or query-parameter injection — see Connect a custom API.

What’s next

• Grants — what a configured provider produces at runtime.
• Connections — the OAuth-grant variant.
• Managed secrets — the operator-provisioned variant.