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.
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 thefields 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.
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 withstatus: '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
A429 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