DatoCMS vs WordPress

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.

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.

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

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