I built a Google Sheets extension that connects to my backend using UrlFetchApp and published it on the marketplace. The addon worked perfectly when it was calling my original server at server1.mysite.com. However, after switching to a new server endpoint at server2.mysite.com (which has a different IP address), I started getting 500 errors on requests.
The weird thing is that when I test the extension in development mode, it works fine with the new server URL. The issue only happens after I deploy it to production. I thought maybe the new server IP needs to be whitelisted somewhere, but I couldn’t find any configuration options for that. The new server itself is working correctly when I test it directly.
Had the same issue with my Google Sheets addon. When you change the endpoint and deploy, the production version often still uses cached settings or old DNS because of Google’s caching. Here’s what worked for me: bump the manifest version number and republish the addon instead of just updating it. Also, make sure your server URL isn’t hard-coded in your scripts - those settings don’t always update with your code changes. Fair warning: it can take up to 24 hours for everything to sync up and stop throwing 500 errors.
check if server2 has the same CORS headers as ur old server. google Sheets extensions are really picky about cross-origin requests - that’s usually why u get 500s in prod but not in dev. also, make sure the ssl cert is valid on server2, that trips ppl up often.
Sounds like a scoping issue with Google Apps Script’s auth system. When you switch server endpoints in production, the extension needs re-authorization for the new domain. I hit this exact problem last year during a backend migration. You’ll need to bump the version number in your manifest and redeploy, but the real fix is checking your OAuth scopes. Make sure they include the new domain and aren’t too restrictive. Google treats different subdomains as separate entities for API calls. Add explicit authorization scopes for the new endpoint in your manifest.json. Also check that server2 returns proper HTTP status codes instead of generic 500s that hide the real auth errors.
This topic was automatically closed 4 days after the last reply. New replies are no longer allowed.