Multi-Channel Content Delivery

Webflow’s content delivery API enables high-performance, low-latency delivery of your CMS content to apps, services, and other platforms beyond your website. These APIs serve published content from a modern cloud edge connectivity network and automate caching, ensuring fast response times for your users.

Content delivery with Webflow

Webflow provides multiple ways to work with your CMS content depending on your use case:

• api.webflow.com: The primary API server for managing CMS content. This uncached server handles real-time content operations (create, read, update, delete). While it always returns the most up-to-date data, response times may be slower since each request must reach Webflow’s backend servers directly.
• api-cdn.webflow.com: For headless content delivery at scale. Serve content consistently across multiple channels like websites, apps, email campaigns, and digital touchpoints while leveraging built-in caching for fast, reliable performance.

Endpoints

The content delivery API provides the following read-only endpoints for accessing published CMS content:

• Get a live collection item: GET /v2/collections/:collection_id/items/:item_id/live
  Retrieves a selected published item from a collection
• List live collection items: GET /v2/collections/:collection_id/items/live
  Retrieves all published items from a collection

To use the content delivery API, replace the standard API domain - api.webflow.com - with api-cdn.webflow.com in your requests. For example:

Authentication

The content delivery API uses the same authentication methods as the Webflow API, supporting both site tokens and OAuth access tokens.

For optimal security and management, create a dedicated API token with CMS Read-Only permissions for each delivery channel. This allows you to independently manage access and quickly revoke access if needed without affecting other integrations. For step-by-step instructions on creating and managing site tokens, see the site token guide.

Caching policy

Caching improves content delivery by reducing server load, minimizing latency, and ensuring reliable performance during high traffic.

Here’s how Webflow’s CDN caching works:

Initial requests

When you first request published CMS data, the request goes to Webflow’s origin servers (e.g. api.webflow.com). The response is then stored in the CDN’s cache. Subsequent identical requests will be served directly from the cache, providing faster response times.

Cache duration

Cached responses are stored for 120 seconds (2 minutes). After this period:

• The cache entry is automatically purged
• The next request will fetch fresh data from the origin server (api.webflow.com)
• The new response is cached for another 120 seconds

This ensures that users receive reasonably up-to-date content while maintaining optimal performance.

Content updates

When you update or delete published CMS items, there may be up to a 120-second delay before changes are reflected in the API responses due to the cache duration. During this period, users may still receive the previous version of the content until the cache refreshes.

Rate limits

The Webflow API includes rate limits that vary based on your site plan. For cached requests that hit the CDN, there are effectively no rate limits. However, uncached requests to the origin server count against your plan’s rate limits.

When you exceed the rate limit, the API will respond with a 429 Too Many Requests status code. To learn more about the specific rate limits for your plan, see the rate limits documentation.

To minimize rate limit errors when working with requests for cached content:

• Implement retry logic with exponential backoff for 429 responses
• Stagger initial, uncached requests to avoid overwhelming the origin server

FAQs