Register an application

A developer on your team is starting a new product. They need IntelliAuth integration. Step one is registering an application against your tenant. Five minutes if you have the answers; longer if you're still figuring out the type or URLs.

Before you begin

Application name — what users will see on the sign-in consent screen
Application type — SPA / M2M / Native / Server-side / SAML
Redirect URIs — where the user comes back after sign-in (browser apps + native)
Audience — the logical identifier of the API the app will call
A sense of which scopes the app actually needs

Open the New application form

Applications → New application (top right of the list view).

A wizard opens. Pages and fields below.

Page 1 — basics

Name — what users see on the sign-in consent screen. "Cymmetri Banking Web" or "Cymmetri Internal Tools". Keep it short and recognisable.
Description (optional) — your team's note about what this app is. Visible to other tenant admins; not surfaced to users.
Type — SPA / Machine-to-machine / Native / Server-side / SAML. See Application types if you're unsure.

Type is the only choice that's hard to change later — pick deliberately.

Page 2 — URLs (skipped for M2M)

Redirect URIs — every URL the browser might land on after sign-in. Multiple allowed; one per line. Production + staging + local-dev all listed here. Full guide: Redirect URIs.
Allowed origins — every browser origin that will call this tenant from JavaScript fetch. Used for CORS. Full guide: CORS.
Logout return URL — where to send the user after a logout completes. Optional; defaults to the application's homepage URL.

For M2M applications, these fields don't apply — M2M tokens are server-to-server, not browser-redirect.

Page 3 — tokens + audience

Audience — the logical identifier of the API this application will call. Usually https://api.cymmetri.com or similar. See Audience for the full thinking.
Allowed scopes — the list of scopes this application is permitted to request. Tenants ship with a default set (openid, profile, email, offline_access). Add custom ones as needed; see Per-app scopes.
Access token TTL — how long the access token lives. Default 1 hour. Tighter for sensitive applications; looser if you have a specific reason.
Refresh token TTL — how long the refresh token lives. Default 14 days for browser apps, 90 days for native. See Token lifetimes.

Page 4 — tags (optional)

Free-form labels for your own use. "production", "customer-facing", "internal", "team:platform". Filterable in the application list.

Save

Click Create. Three things happen:

The application is registered. You see the detail page.
The client_id is generated — visible at the top, copyable. Share this with your developers.
For M2M and Server-side types, the client_secret appears ONCE in a modal. Copy it into your secret manager right now — the platform doesn't let you view it again. If you lose it, you'll have to rotate (Rotate secrets).

What your developers do next

Hand the developers:

The tenant URL (https://<tenant>-<org>.<domain>).
The client_id.
The list of redirect URIs you registered.
The audience string.
The client_secret if applicable (via a secure channel — not Slack, not email).

They follow the developer quickstart (or the Node equivalent) and they're integrating.

Common first-time mistakes

Wrong type. Picking M2M for a browser app or SPA for a backend means redirect/secret behaviour won't match. Browser → SPA. Backend → Server-side or M2M.
Forgot the trailing slash. https://app.cymmetri.com/callback and https://app.cymmetri.com/callback/ are different URIs. Register the exact form your code uses.
Local-dev URI missing. Developers can't test against the application unless http://localhost:5173/callback (or whatever your dev port is) is in the redirect URIs.
Scope list too generous. Easier to add scopes later than to audit which apps have which scope. Start with what's needed.

You can edit every field above on the detail page. Type is the lone exception — set it deliberately on create.