Rate Limits
How to design integrations that stay healthy under bursty editorial and delivery traffic.
When content operations scale, traffic patterns become spiky: large builds, publish waves, preview traffic, and batch imports all compete for the same delivery path.
Default backend limit
Paragraph CMS applies backend-side rate limiting of 5 req/s by default. This is intentional: the platform is designed to discourage client-side article fetching and instead favor generating static pages.
That integration shape is the better default for both SEO and runtime performance. For that reason, prefer @paragraphcms/client over calling the public API directly for article delivery.
When to call the public API directly
Most teams should not call the public API directly for article delivery. Use @paragraphcms/client and generate static pages instead.
Direct API access should usually be limited to backend-only workflows such as preview endpoints, internal sync jobs, editorial automation, and migrations.
If you do build directly on the public API, make sure those workflows handle 429 responses with retry and backoff and avoid high-frequency request patterns.
What rate limits should protect you from
- accidental publish loops;
- excessive preview refreshes;
- asset migration spikes; and
- build systems that request the same content repeatedly with no cache layer.