API
Rate limits, caching and conditional requests
How many calls you can make, what happens when you exceed that, which endpoints are cached and for how long, and how to stop re-downloading content that has not changed.
Last updated September 2, 2026
The Gorilla Dash API is shared infrastructure, so there are limits on how hard any one caller can push it, and read-heavy endpoints are cached. Neither gets in the way of a well-behaved integration, but both are worth understanding before you build something that polls.
The limits
| Limit | Applies to |
|---|---|
| 120 calls a minute | Each API key, counted per calling IP address. |
| 300 calls a minute | Each calling IP address in total, across every key it uses. |
Both apply at once. In practice you will meet the 120 first. Every response carries X-RateLimit-Limit and X-RateLimit-Remaining, reporting whichever of the two limits is closest to being hit.
Go over and you get 429 Too Many Requests with a Retry-After header. Wait for it, then continue — do not retry immediately.
Staying under the limits
- Ask for bigger pages rather than more pages. Contacts, leads, enquiry forms, media and tribes allow up to 1000 records per call; blog articles, knowledge articles, food menu items and digest posts allow 100.
- Poll on a schedule, not in a loop. Once a minute is plenty for almost everything.
- Use
updated_afterso each poll fetches only what changed. See the sync guide. - Cache on your side. If your website asks for the same tribe list on every page view, put it behind your own cache.
- Back off when you get a 429 instead of retrying straight away — hammering a limit keeps you locked out longer.
Which endpoints are cached
The read-only content endpoints are cached, because websites call them constantly and the content changes rarely.
| Cached | Not cached |
|---|---|
| Blog articles | Enquiries — deliberately live, so a new lead is never delayed |
| Knowledge articles | People |
| Food menu items | Send email to a person |
| Digest posts | Tribe search |
| Enquiry forms | Ping |
| Tribes, and the WordPress tribe endpoints | |
| Reviews | |
| Media |
Cached endpoints send Cache-Control: private, max-age=300 and an ETag. Behind that, knowledge articles, food menu items, tribes, the WordPress tribe endpoint, reviews and the single enquiry form are also held server-side for about 30 minutes and refreshed in the background, so a busy website does not hit the database on every request. Blog articles, digest posts, media and the enquiry form list have the five-minute browser cache only.
Conditional requests
Keep the ETag from a response and send it back on your next call as If-None-Match. If nothing has changed, Gorilla Dash answers 304 Not Modified with no body — a much cheaper call for both sides, and it still counts as only one request against your limit.
Treat a 304 as "reuse what you already have", not as an error.
The private in the cache header matters: every response is scoped to your key even though the address is identical for everyone. Never put a shared or public cache — a CDN, a proxy — in front of these calls, or one customer's data can be served to another.