Construct a POST to <org>/api/data/v9.2/$batch with Content-Type: multipart/mixed; boundary=<batch-boundary>
Wrap write operations (POST/PATCH/DELETE) in a changeset part: Content-Type: multipart/mixed; boundary=<changeset-boundary>; operations in a changeset are atomic — all succeed or all roll back
Place read-only GET requests as individual batch parts outside any changeset; GETs inside a changeset are rejected
Use Content-ID headers (Content-ID: 1, 2, …) on parts within a changeset to reference the result of a previous part in the same changeset via $<Content-ID>
Check each inner response's HTTP status code in the multipart response body; a 200 on the outer batch response only confirms the batch was received, not that all operations succeeded
Known gotchas
Changeset rollback is per-changeset, not per-batch: if you have two changesets and the first fails, the second may still execute — design changeset boundaries to match your atomicity requirements
The Dataverse Web API has a limit on the number of operations per batch request; exceeding it returns a 413 error — consult current Microsoft documentation for the exact cap as it may change
Cross-entity references via $<Content-ID> only work within the same changeset; you cannot reference a record created in a previous changeset using this mechanism
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp