API and integration
API rate limit
Last updated by The PanelCompare editorial team
Why does api rate limit matter to a buyer?
The gap between “rate limited” and “broken” is invisible in this API, which is a real operational problem. Errors already come back as HTTP 200 with an error object rather than as status codes, so there is no 429 to back off on and no Retry-After to obey. A client that hits an undocumented cap sees the same generic failure it would see for a bad key or a disabled service, and the usual reflex — retry harder — makes it worse.
The defensive pattern follows from that. Batch aggressively using the 100-ID multi-status form, cache the services response rather than re-fetching a full catalogue per order, back off exponentially on any repeated error regardless of its text, and treat a sudden run of identical errors as a possible cap rather than as an outage. Nothing in the documentation will confirm which it was.
How does api rate limit show up in a price list?
It is undocumented on almost every panel, so it is discovered rather than read. Where a panel does publish one it appears on the API page as a sentence rather than as a field.
Comparison layers above the panels have visible limits of their own, which is a useful illustration of the shape: one competitor index states inline that a free plan opens 10 pages of 200 rows and a paid plan allows 100 searches per hour and 100 pages (observed on smmdir.com, PanelCompare competitor research, 2026-09-06).
Think this definition is wrong?
Terminology in this market is set by the panels that use it, and it moves. If a panel uses api rate limit to mean something other than what is written here, send us the listing and we will either correct the definition or record the variant. The process is on the about page.