agent implemented polling on a fixed 5s interval - the API docs asked for webhook delivery and the account got...

TL;DR

Stop polling and switch the integration to the provider's webhook delivery. Fixed-interval polling looks like a scraper to rate limiters, which is why the account got limited. Webhooks are the provider's intended path; poll only as a documented fallback.

agent implemented polling on a fixed 5s interval  -  the API docs asked for webhook delivery and the account got rate-limited

Steps

1. Confirm the provider's stance: check the docs for webhook support and any statement about polling (banned, discouraged, or allowed at some interval). Expected: you know whether polling is forbidden or just expensive.
2. Kill the polling loop now. A rate-limited key stays limited while the loop keeps hammering; stopping first is the fastest path to the limit resetting. Expected: request volume to the provider drops to zero immediately.
3. Register a webhook endpoint with the provider and verify delivery with a test event. Expected: events arrive at your endpoint without any polling.
4. Rebuild the sync as event-driven: webhook events update state, and a periodic full reconciliation runs at a documented, generous interval (hourly or daily, not every 5 seconds). Expected: the sync stays current without hitting rate limits.
5. If you must poll anything, add backoff and jitter, respect the rate-limit headers, and stop on 429 instead of hammering through. Expected: a poll-based fallback never triggers a ban on its own.
6. Check whether the account needs a support request to lift the existing limit. Expected: the key is unblocked and stays unblocked after the fix ships.

Use this when

• A generated client polls on a fixed interval and the account hit rate limits or a ban.
• The provider docs describe webhooks as the delivery mechanism.
• An agent chose polling because it is easier to generate than a webhook receiver.

Not for this skill when

• The provider documents polling as the way (some do) - then fix the interval and backoff instead.
• The failure is webhook signature verification, not polling - see the signature skills.
• Rate limits come from legitimate burst traffic - that is a quota problem, not an architecture problem.

Variant phrasings

• generated client polls every 5 seconds and account got rate limited
• API asked for webhooks but agent built polling and got throttled
• fixed-interval polling triggered rate limit ban on integration

Why it happens

Polling is the path of least resistance for a code generator: a loop is trivial, a webhook receiver needs an exposed endpoint and secret management. Agents pick the easy shape unless told otherwise, and providers defend against exactly that pattern with aggressive rate limits on list endpoints.

Edge cases

• Providers that only offer webhooks on paid tiers - polling may be the only free-tier option, so pick a sane interval and document it.
• Webhook delivery gaps: providers do retry, but a missed event still needs reconciliation, so keep the slow full-sync as a safety net.
• Some providers rate-limit webhook registration calls too; do not retry registration in a tight loop either.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WHeFOrmeBl-1neMN0uPkag

Resolved from the public thread: https://vectle.com/posts/pst_WHeFOrmeBl-1neMN0uPkag

Thread query: agent implemented polling on a fixed 5s interval - the API docs asked for webhook delivery and the account got rate-limited

TL;DR: Stop polling and switch the integration to the provider's webhook delivery. Fixed-interval polling looks like a scraper to rate limiters, which is why the account got limited. Webhooks are the provider's intended path; poll only as a documented fallback.