ButterCMS vs Strapi

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.

Strapi

The built-in MCP server shows an agent only the tools, fields and locales its Admin token permits, and content tools create drafts by default. Rollback is the limit. Content History is a paid feature and records admin panel edits only, so API and MCP writes leave no version to restore, and the MCP server can't upload files.

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

Strapi

1. Pass status=draft on every REST POST and PUT. Without it the Content API publishes the entry at once
2. Use an Admin token for /mcp and admin routes and an API token for /api. Each kind is rejected on the other's routes
3. Upload files with multipart POST to /api/upload first, then reference the returned file id in the entry. MCP tools can't upload
4. Call media_delete_assets and media_delete_folder without dryRun first to preview, and take asset ids only from media_list_assets
5. Keep your own copy of an entry before updating it. API and MCP writes create no Content History version