OAuth Redirect URI Mismatch - AppFoundry App

NICE CXone API & Integrations
1

Hi all,

We’ve got a really frustrating issue with an AppFoundry application’s OAuth flow when deployed across multiple organizations. It’s intermittent - some orgs work perfectly, others throw a redirect URI mismatch error. It’s causing significant delays for a client rollout, and honestly, it feels like a configuration quirk.

The setup is fairly standard. We’re using the multi-org OAuth flow as documented - creating a client in each org pointing back to our application’s redirect URI. The application itself is built using the Genesys Cloud React SDK - currently on version 4.2.1. We’re hitting the /api/v2/oauth/authorize endpoint to initiate the flow, then handling the callback at the configured redirect URI.

What’s odd is the error isn’t consistent. It seems to crop up more frequently after initial deployments to new orgs, or when an organization makes changes to its OAuth settings. The error message in the browser is pretty generic - just “redirect_uri_mismatch” - but the logs on our side show the authorization request being sent with the correct redirect URI. I’ve seen a similar issue come up in the community a few times, usually relating to whitespace or subtle differences in the URI, but we’ve triple-checked for those. One post mentioned it being a caching issue with Genesys Cloud, but that didn’t seem to resolve it.

We are seeing the error manifest most consistently with clients who have a very complex set of security policies configured within their orgs. It feels like something isn’t propagating correctly. We’ve had to work around it temporarily by manually re-initiating the authorization flow several times.

Here’s a quick rundown of what we’ve tried:

  • Verified the redirect URI is exactly the same in the AppFoundry application configuration and in each organization’s OAuth client settings.
  • Cleared browser cache and cookies.
  • Verified the client ID is correct in all locations.
  • Checked for any URL encoding issues with the redirect URI.
  • Tested with multiple different browsers.
  • Reviewed the OAuth 2.0 documentation again - looking for any overlooked step.
  • Checked the AppFoundry app’s permissions to ensure no unexpected changes.

The logs show the initial authorization request looks fine, but the callback URL is being rejected. It’s like the platform isn’t remembering the initially authorized URI. Anyone run into something like this before? It is making things difficult to scale.

2

It’s like trying to fit a square peg in a round hole - the redirect URI needs to be precisely the same, or the OAuth flow rejects it. We spent two coffees debugging this exact issue. The application registration in each organization must have the exact same callback URL.

{
 "redirectUris": [
 "https://your-app-url.com/oauth/callback"
 ]
}
2 Likes
3

That’s right, the redirect URI has to match exactly - we saw this brick the Architect sync flows last quarter when a change went live in us-east-1. It wasn’t the URI itself, though - it was the trailing slash. Some orgs had https://your-app-url.com/oauth/callback/ while others just had https://your-app-url.com/oauth/callback.

Check the application registration in each organization’s admin UI - look for that extra forward slash. It’s easy to miss. Also - are you pulling the redirect URI dynamically from a configuration file? If so, double-check the environment variables in each org. We had an environment variable typo cause a similar mess, and the logs just showed a generic OAuth failure.

It’s a pain, but the OAuth flow’s that brittle. Saw a similar issue pointed out in the thread about predictive routing analytics - the parser doesn’t handle inconsistencies well.

4

That trailing slash is a mess - we’ve seen it pull down deployments more than once. platformClient.api.oauth.client.get will show you the registered redirect URIs - confirm the casing and the slash are identical across orgs.

{
 "redirectUris": [
 "https://your-app-url.com/oauth/callback"
 ]
}

It’s usually a deployment script copying the config - check the variable substitution there.