Redirect URIs

A redirect URI is the URL the browser is redirected to after the user signs in. IntelliAuth only sends users to URIs that are pre-registered on the application; anything else returns invalid_redirect_uri and the user is stuck on the IntelliAuth error page.

You'll spend more time on this than you expect.

Where to set them

Open the application's detail page → Settings tab → Redirect URIs. One URI per line. Save.

The platform validates each entry on save — malformed URIs are rejected with a clear message.

What "exact match" means

The platform matches the URI character-for-character against what your code sends. That includes:

Scheme — https vs http.
Host — app.cymmetri.com vs www.app.cymmetri.com vs cymmetri.com. Different.
Port — omitted vs explicit (:443). Treated as the same after normalisation; rare gotcha.
Path — /callback vs /callback/. Trailing slash matters.
Case — paths are case-sensitive (/Callback ≠ /callback).

The error message in the audit log when this fails is literally "submitted: <what your code sent>, registered: <what we have>". Compare character by character.

Common URIs for different app types

For a typical web SPA, register all of:

https://app.cymmetri.com/callback
http://localhost:5173/callback

The first is production. The second covers the typical Vite dev server. Some teams also add:

https://staging.cymmetri.com/callback
http://localhost:3000/callback

Adding a few extras now is cheap; adding them under fire-drill is annoying. Pre-register your environments.

For a native app, register the custom URI scheme:

com.cymmetri.banking://callback

Some platforms support a loopback HTTP listener for native too:

http://127.0.0.1/callback

Per RFC 8252 §7.3, the platform wildcards the port on loopback URIs — http://127.0.0.1:any-port/callback matches a registered http://127.0.0.1/callback.

Wildcards (not supported, mostly)

The platform refuses wildcards in redirect URIs:

https://*.cymmetri.com/callback        ← refused
https://app.cymmetri.com/*             ← refused

Per RFC 8252 + the OAuth 2.0 best-current-practice guidance, wildcards are an open-redirect risk. The platform offers no toggle for them.

The one exception: loopback IPs on native apps (above), where the port is wildcarded by spec.

Multiple environments

Two common patterns:

One application per environment — register a separate IntelliAuth application for production / staging / uat. Each has its own redirect URIs. Cleaner; preferred for production.
One application across environments — register all environments' redirect URIs on a single application. Simpler; common for early-stage projects. Drift starts when production has 3 URIs but staging accidentally has 5.

The cost of "one application per environment" is the extra registration. The cost of "one application across environments" is harder audit ("which URI sees real customer traffic?"). Production deployments usually prefer the former.

Production-time guidance

Don't ship a release with new redirect URIs without registering them first. The window between deploy and registration is when users get the "Sign-in configuration error" message.
Keep dev-only URIs (http://localhost:*) on the production application only if your developers also test against production. Otherwise put them on the staging application.
When you decommission a host (deprecated subdomain, moved to a new domain), remove the URI from the application. Stale URIs are technical debt; eventually one is hijacked or pointed at a third party.

When the developer says "it's not working"

Walk these checks in order:

What URI is the code actually sending? Network tab → /oauth2/authorize?...&redirect_uri=.... The URI is URL-encoded; decode it.
What URIs are registered? The application's Settings tab → Redirect URIs.
Diff them. The character-by-character comparison usually reveals a trailing slash, an http/https mismatch, or a host typo.

The invalid_redirect_uri developer troubleshooting topic is the same diagnostic from the developer's side.