ButterCMS vs Sanity

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.

Sanity

Sanity publishes 26 OpenAPI specs covering 225 operations, and its hosted MCP server saves edits to drafts or release versions, with publishing as a separate call. The Content Lake does not run schema validation on API writes, and custom roles that limit a token to one dataset or document type are sold only on Enterprise plans.

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

Sanity

1. Pin a static dated version in every URL, such as v2025-02-19. Omitting apiVersion in @sanity/client falls back to v1.
2. Validate documents against the schema yourself before an HTTP write, or run sanity documents validate afterwards. The Content Lake does not enforce schema rules.
3. Back off on 429 for mutations yourself. @sanity/client retries queries five times but never retries mutations. The limit is 25 mutations a second per IP.
4. Over MCP, call create_version before patch_documents when editing inside a release, then patch the returned version ID with the same releaseId.
5. Use GROQ projections and slices to size results. MCP query responses are limited to 64 KiB, and a blocked Free project answers 402 with plan_limit_reached.