ButterCMS vs WordPress

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.

WordPress

The REST API is part of core, and a post created without a status is saved as a draft with revisions kept on the owner's server. Application Passwords carry no scopes, so limits come only from the user's role. Revisions can be read and deleted but not restored over REST, and a critical flaw was fixed on 22 September 2026.

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

WordPress

1. Ask the owner for a dedicated user with the lowest role that fits. A Contributor can draft and edit its own posts but can't publish them
2. Send the Application Password as Basic auth over HTTPS only. Core disables Application Passwords on plain HTTP outside a local environment
3. Upload a file with POST /wp-json/wp/v2/media first, then set featured_media or reference the returned URL in the post content
4. To roll back, GET /wp/v2/posts/<id>/revisions/<rev>?context=edit and POST its title and content to the post. There's no restore route
5. Pass _fields=id,status,link,modified on lists and read X-WP-TotalPages. per_page stops at 100