I created a Google Sheets Add-on that connects to my backend server using UrlFetchApp for API calls. The add-on is published on the Google Marketplace and works perfectly with the original server endpoint.
The issue started when I needed to switch from my first server (api.domain.com) to a new server (api2.domain.com) which has a different IP address. After updating the URL in my code and redeploying the add-on, I get a 500 error whenever it tries to make requests to the new server.
The strange thing is that when I test the add-on in development mode, it works fine with the new server URL. The problem only happens after I deploy it to the marketplace. I think Google might be blocking requests to the new IP address, but I cannot find any whitelist settings to configure this.
This sounds like DNS propagation mixed with Google’s CDN caching. When you deploy to the marketplace, Google serves your add-on through their infrastructure - they’ve probably cached the DNS resolution for your old domain. Dev environment bypasses this caching, which explains why it works there.
I hit the same issue last year during a server migration. Waiting 24-48 hours for DNS changes to fully propagate through Google’s systems fixed it for me. Also check if your new server has the same SSL certificate setup as the old one - any TLS differences can cause those 500 errors. Make sure your new server’s firewall allows requests from Google’s IP ranges too, since they’re the ones making the actual API calls for your add-on.
Had the same headache migrating our add-on infrastructure. When dev mode works fine but you’re getting 500 errors, it’s usually auth or CORS differences between servers. Google’s marketplace runs through their proxy system, so your new server’s probably rejecting requests that don’t match expected origin headers or auth tokens. Check that your CORS settings and API keys match exactly between old and new servers. Also make sure any IP restrictions account for Google’s request origins. New server environments often have stricter security defaults - they’ll work for direct testing but block Google’s proxied requests. Try rolling back temporarily to see if the old server still works. That’ll tell you if it’s your server config or actually a Google caching issue.
yeah could be a cache prob. try bumping your version in the manifest and redeploy it all. also, make sure there ain’t any hardcoded links to the old api still lingering around.