Rate limiting

Plan for 1 request per second per integrator. Contact [e-mail] to request a higher quota.

Plan for 1 request per second

Sustained polling on the order of one request per second per integrator is the typical traffic profile for these endpoints. Build your sync logic around that rate — most integrators sync every few minutes during an active event and every hour or so once events have closed.

Need a higher quota? Contact [e-mail] before scaling up your traffic so the team can review your use case and adjust your account’s rate limits accordingly.

When you exceed the rate limit

If you push past the shared rate-limit zone, you’ll see one of:

Status	When
429 Too Many Requests	Short-term burst above the allowed rate. Back off and retry.
503 Service Temporarily Unavailable	Sustained traffic above the rate-limit zone capacity, or an upstream component is overloaded.

In both cases, the right response is to back off with exponential delay before retrying. Avoid tight retry loops — they make the problem worse.

If you see persistent 429s or 503s with normal traffic, that’s a signal to contact [e-mail] to discuss your traffic profile.

Recommended polling cadence

Event state	Suggested polling interval
Active event (people are bidding / checking out right now)	Every few minutes
Post-event reconciliation	Hourly
Idle / historical sync	Less frequently

Avoid sub-second tight loops — they exhaust the rate-limit budget quickly and don’t give the database time to commit incoming changes.

Why concrete thresholds aren’t published

Rate-limit thresholds vary by region and infrastructure capacity, and are tuned periodically. Publishing exact numbers would create a moving target. One request per second is the practical target — if your integration needs to go higher, reach out and Givergy will work with you on a sustainable plan.