INTASTELLAR SOLUTIONSHelp Center
Versionv1

Intastellar only completes return flows to URLs you pre-registered (or URIs your client allows for the login URI used by the React / plain JS flows). A typo, wrong scheme, or extra slash causes redirect_uri_mismatch (or similar) — the error looks technical, but the cause is usually “the URL doesn’t match the list”.

If you change hostname (domain migration, new CDN), update the Intastellar client so redirect / login entries match the new origin and paths. SDKs often derive a login URI from the current page (hostname, port, pathname) unless you override it — register what you actually send.

Quick checks when it “suddenly broke”

  1. Compare scheme: https:// vs http://.
  2. Compare host: www. vs bare domain.
  3. Compare path: /callback vs /callback/.
  4. Compare port in dev: 127.0.0.1 vs localhost.
  5. Confirm you updated staging client vs production client.

Rules of thumb

  1. HTTPS in production — http://localhost is often allowed for development; production should use https://.
  2. Exact match — https://app.example.com/callback and https://app.example.com/callback/ are different paths; register the one you use in the authorize request.
  3. No wildcards in most setups — register each concrete callback path (or follow your console’s documented pattern if path templates are supported).
  4. Query strings — avoid dynamic query strings in the registered URI unless registration explicitly allows it; prefer a fixed path and pass internal context via state.

Multiple environments

Register separate redirect URIs (or separate clients) for:

  • Local development (http://127.0.0.1:5173/auth/callback, etc.)
  • Staging
  • Production

This limits impact if a non-production secret leaks.

SPA routers

If you use hash routing (/#/callback), check whether redirects to that pattern are allowed; many setups require path-based URLs (/auth/callback) for OAuth callbacks.

On the callback route (after redirect)

  1. Read code and state from the query string.
  2. Verify state against what you stored when you started the flow.
  3. Exchange the code at the token endpoint — Authorization code flow.
  4. Redirect the user to the final in-app destination (dashboard, return URL stored in state, etc.).

Frequently asked questions

SDK popup flow — do we still need redirect URIs?

You still need correct client registration and often a registered login / continue pattern. If something fails before the popup finishes, compare what the SDK sends with what is registered — see your integration notes.

We fixed the URL in our code but it still fails

The list in the Intastellar client must change too. Deploying new code does not update registration automatically.

Next

Sessions, cookies, and tokens — persist the signed-in user safely after a successful callback.

Last updated