504/502 Gateway Errors on Esper Console Caused by Excessive API Polling from Customer Automation

Android

Title: 502/504 gateway errors on Esper Console — caused by API over-polling

When an automation script or integration polls the Esper API at very high frequency, the resulting request volume overwhelms the API gateway and produces 502 Bad Gateway or 504 Gateway Timeout errors that block access to the Esper Console for all users on the account.

Why this happens

The Esper API gateway enforces request limits to maintain platform stability. When a script — most commonly one that repeatedly fetches application version data — sends requests far faster than the rate limit allows, the gateway begins rejecting traffic. Because the gateway sits in front of the entire platform, this can make the Esper Console appear inaccessible even though no platform-wide outage exists.

Before you start

Confirm the issue is specific to your account, not a platform-wide outage, before investigating your own systems:

Try logging in to the Esper Console from a different browser or an incognito window.
Try logging in from a different network (for example, a mobile hotspot).
Check the Esper status page for any active incidents.

If the Esper Console loads successfully after these checks, the gateway has recovered and you can move directly to Step 3 to prevent recurrence. If the Console is still inaccessible, continue with Step 1.

Steps

Identify recently changed automation. Review any scripts, scheduled jobs, RPA tools, or third-party integrations that query Esper APIs — particularly ones that were deployed or modified shortly before the errors began. Focus on automation that fetches application version data, as this is the most common source of high-frequency polling.
Pause or stop the suspected automation immediately. Disable every script or integration identified in Step 1. Stopping the request flood allows the API gateway to recover. Once paused, wait 5–10 minutes, then attempt to log in to the Esper Console again.
Update your automation to respect API rate limits. Before re-enabling any script, apply the following changes:
- Reduce polling frequency: Poll no more than once every 60 seconds for any non-critical data endpoint.
- Add exponential backoff: When an API call fails, double the wait interval before retrying rather than immediately re-sending the request.
- Cache responses locally: Store results such as application version data in a local cache and serve from that cache instead of re-fetching on every cycle.
- Batch requests where possible: Combine multiple queries into a single API call rather than issuing them individually in rapid succession.
Re-enable your automation and monitor console access. Turn your updated scripts back on one at a time. After each one is re-enabled, confirm the Esper Console remains accessible before proceeding to the next.

Verify: The Esper Console should load normally within 5–10 minutes of pausing the over-polling automation. After re-enabling the updated scripts, sustained console access with no further 502 or 504 errors confirms the rate-limiting changes are working correctly.

If this doesn't resolve it

If the Esper Console is still inaccessible after pausing all automation and waiting 10 minutes, or if you cannot identify a script responsible for the polling, contact Esper Support. When you reach out, include:

The approximate time the errors first appeared.
The exact error message or HTTP status code shown in your browser.
A description of any automation or integrations your team runs against the Esper API, including polling intervals if known.
A screenshot or network trace showing the 502 or 504 response, if available.

Still need help?

If you're still experiencing 504/502 errors after reviewing your API polling frequency, please submit a support ticket and include your current API polling interval, the number of devices being polled, and any automation scripts or integrations that may be triggering excessive requests.