App downgraded after webhook retry loop caused excessive API traffic — root cause fixed, seeking gui

[joaojato]

Hi everyone,

My Web API app was recently downgraded after producing an abnormal volume of requests. I've identified and fixed the root cause, and I'm sharing here in case it helps others — and to ask if anyone has gone through the reinstatement process.

What happened

My app is a personal, non-commercial tool I built to organize my own playlists using custom tags. It integrates with a Telegram bot that triggers playlist synchronization on demand.

The sync operation iterates through ~50 playlists and their tracks, which takes several minutes. The bug: my webhook handler was awaiting this long-running operation before returning a response to Telegram. When Telegram's webhook timeout elapsed without a 200 OK, it retransmitted the same update. The bot treated it as a new request and started another concurrent sync — which again timed out, triggering yet another retransmission. This loop ran for hours, producing far more API requests than intended and eventually triggering a Retry-After: 14400 minutes response, followed by the downgrade notice.

Fixes already deployed

1. Global request throttle in the Spotify client (~5 req/s).
2. In-memory mutex preventing concurrent syncs — duplicate triggers now return immediately.
3. Persistent Retry-After handling — severe cooldown values are stored and respected; no requests are made until the window expires.
4. snapshot_id-aware sync — playlists with no upstream changes are skipped entirely, drastically reducing unnecessary calls.
5. Fire-and-forget webhook handlers — long operations are now decoupled from the HTTP response, so Telegram always gets a 200 OK within a second. This eliminates the retry loop entirely.

Question

Has anyone successfully gone through the reinstatement process after something like this? Any tips on what the support team typically looks for, or how long the process tends to take?

Thanks in advance.