Introduction

Whether you’re syncing environments, migrating thousands of entries, or automating mass updates – at some point you end up using the Contentful Content Management API (CMA). I will explore the other APIs here also but this is the big one.

The CMA is your entry point to interact with the Contentful management environment through code and depending on what you’re doing you’ll eventually hit the limits. When that happens, the interface might not load, if your doing ingestion it might slow or fail.

This post outlines how the limits work, how to monitor them, and most importantly how to build resilient, scale-friendly code interactions that won’t get throttled mid-run.

Rate limits are a good thing

SaaS software platforms need to be available 99.99% of the time and the distributed architecture means multiple components will be used to serve your request.

A rate limit protects the infrastructure meaning if something fails for you it should be ok for other requests you or others make.

Understanding Contentful Rate Limits

Contentful provides multiple APIs, each designed for a different purpose. Knowing when to use each – and how they’re rate-limited – is critical for building performant and compliant applications.

Content Management API (CMA)

• Purpose: Used for creating, updating, and deleting content in the Contentful web app or via custom tools. It powers editorial workflows, integrations, and automation.
• Access: Requires authenticated access with a Content Management Token.
• Limits (2025):
  • Free Plan: 7 requests/sec per space
  • Paid Plans: 10 requests/sec per space
• Common Use Cases:
  • Content ingestion pipelines
  • Automation scripts for metadata updates
  • Managing entries and assets programmatically

Content Delivery API (CDA)

• Purpose: Designed for delivering published content to your end users. It powers websites, mobile apps, and other front-end experiences.
• Access: Requires a Content Delivery Token (read-only).
• Limits (2025):
  • Free Plan: 55 requests/sec per space
  • Paid Plans: 78 requests/sec per space
• Common Use Cases:
  • Fetching blog posts or product content for your front-end
  • Powering static site generators like Gatsby or Next.js
  • Integration with mobile apps

Content Preview API (CPA)

• Purpose: Enables previewing unpublished content – such as drafts or scheduled entries – for staging environments or preview buttons in your CMS UI.
• Access: Requires a Preview API token (read-only).
• Limits (2025):
  • Free Plan: 14 requests/sec per space
  • Paid Plans: 20 requests/sec per space
• Common Use Cases:
  • Preview links from your CMS
  • Integrations for editorial QA workflows
  • Review staging environments with upcoming content

Typical Failure Scenarios

Here’s when teams usually hit the wall:

• Bulk ingestion or migration scripts: Updating entries, assets, or content trees in parallel
• Webhook feedback loops: Webhooks that trigger updates on other entries
• Unoptimized polling: Continuously querying entries or assets without caching or filtering
• Missing deduplication or batching: Repeated updates to the same entry in short bursts

Ways to mitigate request limits

1. Throttle the number of requests that you are making. Especially if you have multiple app framework components active. Potentially add in a delay between requests.
2. Add in retry to all API calls for resilience. As the API can return a 429 at anytime to protect itself be ready to retry a specific number of times. Also if retrying possibly increase time between retries at a multiplier for additional protection.
3. If building app framework app’s possibly use a mix of CMA and CPA. CMA for updates and CPA for reads. This should give additional headroom and reduce timeouts.
4. Use queues is another option. For any updates a message queue could mean they can be processed slower. This would also help with deduplication of updates to certain content entries.
5. Console log as much as you can, this is an invaluable way to see what components are doing and provide realtime feedback

Conclusion

The Contentful APIs are a powerful tool – however misuse and possibly naive processes will break it under scale.

Understanding the true rate limits (no burst, no hourly buffer) and designing with throttling, retries, and queueing will save your team hours of frustration and prevent headaches.

In short:

Throttle every request

Retry intelligently

Offload when needed

Log everything

Your Contentful experience will be faster, safer, and ready to scale.