Skip to main content

Overview

For Collections, POST /v2/content/ accepts multiple items in a single request by passing an array of item objects in fields. This is the most efficient way to bulk-create Collection items, since it’s one HTTP call instead of one per item. Pages and Blog Posts don’t have an equivalent multi-item endpoint, so bulk operations on those content types (and any per-item update/delete/publish on Collections) still require orchestrating multiple Write API calls. This guide covers patterns and best practices for both.
Write API access requires a Write API Token. It’s a paid add-on for Advanced and Professional plans; purchase it from Settings > Billing in your dashboard. It isn’t offered on Basic plans; upgrade your plan or contact support.

Key Considerations

  • Request Pacing: Add small delays between requests to keep bulk operations stable and reduce monthly usage spikes.
  • Error Handling: Implement retry logic for transient failures.
  • Progress Tracking: Track successful and failed operations for large imports.
  • Async Nature: Write operations return 202 Accepted—content typically appears within seconds but processing time may vary.

Bulk Create Pattern

Single-Request Batch Create (Collections)

The fastest way to bulk-create Collection items: pass every item as an entry in the fields array of one POST /v2/content/ call. The collection key goes in the body as key, not in the URL. The response is a single 202 {"status": "pending"} with no item IDs. Writes are asynchronous, so verify the created items via the Read API afterward.
For very large imports, split items into chunks (e.g. 50-100 per request) and pace the chunked requests rather than sending one request per item.

Sequential Creation with Request Pacing

Use a per-item loop when you need per-item error tracking, or for content types without a batch-create endpoint (Pages, Blog Posts):

Parallel Creation with Concurrency Control

For faster bulk operations, use controlled concurrency:

Bulk Update Pattern

Update Multiple Items by ID

Include status: 'published' in every update. Without it, the changes are saved as a draft revision and the live content does not change.

Publishing Draft Items

The Write API cannot publish a collection item that was created as a draft. A PUT or PATCH with status: 'published' publishes the new field values, but the item itself stays hidden from production reads. Publish draft items from the Collections dashboard, which supports selecting several items at once. A PATCH that sends only status without fields returns 400.

Bulk Delete Pattern

Content Migration Example

WordPress to ButterCMS Migration

Handling 429 Responses

A 429 from the Write/Read API means your account’s monthly API call limit has been exceeded (Free/Trial plans). Retry-After reflects the time until your next monthly reset, which can be hours or weeks away, so a quick retry loop won’t resolve it. Stop the bulk operation, surface the limit to a human, and either reduce call volume or upgrade your plan.

Progress Tracking and Logging

Best Practices

Request Pacing

Add 200-500ms delay between requests to keep bulk operations stable and reduce monthly API usage spikes.

Idempotency

Check if content exists before creating to avoid duplicates during retries.

Error Logging

Log failed operations for manual review and retry.

Batch Verification

After bulk operations, verify content via Read API.

Suggested Starting Points

ButterCMS doesn’t enforce a concurrency cap or minimum delay between requests for most accounts. These values are guidance to keep your own bulk jobs stable and avoid using up your monthly API call quota too quickly.
Free/Trial accounts can be blocked for the rest of the billing month when their monthly API call limit is exceeded. See Handling 429 Responses.

Next Steps

Pages - Write

Create and update pages

Collections - Write

Create collection items

Blog Posts - Write

Create blog posts

Rate Limits

API rate limiting