ButterCMS vs DatoCMS

ButterCMS

The Read and Write APIs have a public OpenAPI 3.1 file, Markdown docs and a status page with no incident since October 2025. The Write API is a paid add-on from the $249 plan, capped at 2,000 or 5,000 calls a month. Writes answer 202 with no identifier, support rotates tokens, and the terms are an undated website document.

DatoCMS

The Content Management API publishes a JSON Hyper-Schema for 202 operations, 100 documented error codes and rate-limit headers, and the hosted MCP server adds OAuth with three access levels. There are no idempotency keys, the only official client library is JavaScript, audit logs are Enterprise only, and prices are in euros with no machine payment route.

ButterCMS

1. End every path with a slash. A missing slash returns a 301, and the vendor counts the redirect and the retry as two API calls
2. Send the write token only as Authorization: Token <token>. The auth_token query parameter works for reads only
3. On page creation send every field key of the page type, with empty strings for fields left blank
4. A 202 means queued, not saved. Read the entry back with preview=1 to confirm, and check a slug exists before retrying a create
5. Call the REST API directly for writes. The JavaScript SDK 3.0.3 has list, retrieve and search methods only

DatoCMS

1. Send X-Api-Version: 3 and Accept: application/json on every request, with Content-Type: application/vnd.api+json on writes
2. Records are items, models are item_types and assets are uploads in every path and payload
3. Save a record, then call the publish endpoint as a separate PUT. Send meta.current_version on updates and re-fetch on STALE_ITEM_VERSION
4. Stay under 60 requests every 3 seconds. On 429 wait the seconds in x-ratelimit-reset, and retry any error whose body has transient set to true
5. Fork a sandbox environment for schema changes and promote it when checked. Use POST /items/validate to test a payload without saving it