Social listening app fails OAuth authentication after cloud redeployment

CRM Zendesk Sell
, , , , , , , ,
1

We’ve redeployed our social listening integration app to a new cloud environment with a custom domain, and now OAuth authentication is completely broken. Users trying to connect their social media accounts get a redirect_uri_mismatch error from the OAuth provider. The OAuth flow worked fine in our previous deployment. I’ve updated the redirect URI in our OAuth app configuration to match the new cloud domain, but authentication still fails. The error suggests the redirect URI doesn’t match what’s registered, but I’ve triple-checked and it looks correct. I suspect there’s something about the custom domain setup or how the cloud environment handles OAuth callbacks that I’m missing. The app is completely unusable without working OAuth. Anyone dealt with OAuth redirect URI issues after cloud migration with custom domains?


OAuth Provider: Twitter/X API v2
New Domain: social.ourcompany.com
Redirect URI: https://social.ourcompany.com/oauth/callback
Error: redirect_uri_mismatch
2

I’ve debugged this exact issue before. The problem is often that your application is generating OAuth redirect URIs based on the internal cloud hostname rather than your custom domain. Check your application’s base URL configuration in Zendesk Sell. If it’s set to the default cloud hostname instead of social.ourcompany.com, all generated OAuth URIs will be wrong. You need to explicitly configure your app to use the custom domain for all OAuth flows, not rely on auto-detection.

3

Check if your cloud deployment is behind a reverse proxy or API gateway. These often rewrite URLs, and if the OAuth callback comes through the proxy, the actual redirect URI might be different from what you registered. You may need to configure X-Forwarded-Host and X-Forwarded-Proto headers so your application generates correct redirect URIs.

4

The redirect_uri_mismatch error is very literal - the URI in your OAuth request doesn’t exactly match what’s registered. Check for trailing slashes, http vs https, and even www vs non-www. Also verify that your cloud load balancer isn’t modifying the redirect URI. Some load balancers add ports or change protocols, which breaks the exact match requirement.