Skip to content

Admin

Setting Up an App

Create an app, configure providers, mint API keys.

An app is the unit that owns API keys, provider configuration, and grants. Most products have one app per environment (production, staging). This page covers the operator setup from zero to “the SDK can make calls.”

A brand-new workspace comes with a starter app named My First App — rename it from its settings and use it directly, or delete it. To create another app, open the Applications dashboard in the developer portal at portal.alterauth.com, select the Create application card, enter a name, and select Create Application.

For a multi-environment setup, create a separate app per environment (product-prod, product-staging). Each app has its own keys, grants, and provider configuration — no chance of a staging credential reaching production.

Two kinds of providers, configured on different portal pages.

For credentials end users authorize themselves (Google, Slack, GitHub, …):

  1. Open the app and select OAuth in the sidebar. On the OAuth Providers page, select Add Provider.
  2. Pick the provider from the catalog (or Custom OAuth for anything not listed).
  3. Follow the per-provider instructions to register an OAuth client at the provider and paste back the Client ID and Client Secret.
  4. Add Alter’s redirect URI (shown in the portal) to the provider’s allowed callback list.
  5. Pick the default scope set.

Full catalog: OAuth providers reference.

For credentials the operator owns (Datadog API key, AWS access key, …):

  1. Open the app, select Managed Secrets, then select Add Managed Secret.
  2. Pick the provider from the catalog (or Custom for any header-based credential).
  3. Paste the credential. It’s encrypted and sent to the vault; the portal will not display it again.
  4. Issue at least one grant binding the credential to a principal.

Full catalog: Managed secret providers reference.

If the app has logged-in end users, wire an identity provider so the SDK can resolve users from their JWTs. Skip this step for backend-only apps and operator scripts.

Open Branding to set the logo, colors and font the Connect consent screen shows the app’s end users. Branding requires a plan that includes custom branding (Starter and above); on a plan without it the editor is replaced by an upgrade prompt. Resetting to Alter’s default branding stays available on every plan, so an organization that downgrades can still clear branding it can no longer edit.

A hosted https:// logo is fetched when it is saved and the result is reported inline. The common mistake is pasting the address of a page showing the image rather than the image file itself: the part after # never reaches the server, so only the page is fetched. The save still goes through and the notice reports that the logo will not display. A destination resolving to a loopback, link-local, private or reserved network is rejected before the write so the consent screen cannot make an end user’s browser request that user’s network. Uploaded images skip the fetch; their format is validated on upload.

Fonts are fetched by Alter and served from Alter’s own origin, so no end user’s browser makes a request to a third-party font host.

The same settings are scriptable with alter branding.

Open API Keys and select Create key. The plaintext (alter_rk_…) is shown once — copy it into a secret manager and revoke if it’s ever lost.

See API keys for rotation, per-agent keys, and scoped derivation.

Run the Quickstart GitHub flow against the new app, or run any of the guides. If the first call returns a 2xx response from the provider, setup is complete.

Report an issue with this page

Necessary

Required for sign-in, security, authorization, and remembering your choices.

Always active

Analytics

Helps us understand which product and documentation features are useful.

Performance diagnostics

Uses performance tracing and privacy-masked session replay to diagnose problems.

You can change these choices at any time from Cookie settings.