An integration sends PATCH requests to the Dataverse Web API at accounts({id}) to update account rows by GUID. If a row has been deleted, the integration must receive an error instead of silently recreating the account with that ID. Which header should the request include?
Select an answer to reveal the explanation.
Short Explanation
A plain PATCH to a specific ID is an upsert: if the row isn't there, Dataverse happily creates it. Add If-Match: and you're saying "only if it already exists." The trap is If-None-Match: , which does the exact opposite and blocks updates.
Full Explanation
In the Dataverse Web API, a PATCH request to an entity's URL with a specific key performs an upsert by default: it updates the row if it exists and creates it if it does not. Adding the If-Match header with the value tells the service to proceed only when a row with that key already exists, so a deleted account produces a 404 Not Found response instead of being recreated. If-None-Match: expresses the opposite intent: it allows the PATCH to create a row only when none exists and rejects the request if the row is present, so it would block every normal update and still allow re-creation of deleted rows. Prefer: return=representation asks the service to return the updated row in the response body; it does not change upsert behavior, so a missing row would still be created. If-Match: null is not a valid way to suppress upsert; the special wildcard value is , while a concrete ETag value is used for optimistic concurrency. Exam caveat: when the requirement is optimistic concurrency rather than existence, If-Match carries the row's ETag, and a mismatch returns 412 Precondition Failed. Operational check: delete a test account, send the PATCH with If-Match: , and confirm the response is 404 and that no account with that ID is created.