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
protects the delivery API from accidental request bursts and discourages
client-side article fetching.
Server-side rendering (SSR) is the recommended integration model. Keep content requests on the server and cache public rendered responses at your deployment layer. This gives visitors fast responses without making the CMS API part of every browser interaction.
When to call the public API directly
Use @paragraphcms/client from
server-only code for article delivery. The client does not replace caching:
configure that separately for the platform where your SSR app runs.
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.