ButterCMS vs Payload

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.

Payload

Payload generates REST, GraphQL and MCP interfaces from one typed config, with drafts, restorable versions and per-key MCP permissions in the free MIT core. The security record is the limit. The vendor published 49 advisories in 12 months, 8 of them critical, so an install older than 3.90.0 is exposed. No OpenAPI file is published.

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

Payload

1. Check the installed version first. Anything below 3.90.0 carries published critical advisories, so ask the owner to upgrade before writing
2. Send REST keys as Authorization: {collection-slug} API-Key {key} and MCP keys as Authorization: Bearer {key}. The two key kinds are separate
3. To publish, set _status: 'published' in the data. The draft parameter only relaxes validation and chooses where an update is written
4. Upload files with multipart POST to the upload collection, with other fields as JSON in _payload. No MCP upload tool is documented
5. Roll back with POST /api/{collection-slug}/versions/:id after listing versions. Versions exist only where the collection config enables them