Ava API Client

Guide

How to fix If-Match and ETag errors in the Business Central API

Updated 2 November 2026

Updating a record in Business Central requires an If-Match header. It holds the record's ETag, a version stamp that says which version you read. If someone has changed the record since, the update is refused, and their change isn't silently overwritten.

The steps

1. Read the record

GET .../companies(<company-id>)/customers(<customer-id>)

The ETag comes back in the response as @odata.etag:

{
  "@odata.etag": "W/\"JzE5OzEyMzQ1Njc4OTA7Jw==\"",
  "id": "...",
  "displayName": "Adatum Corporation"
}

2. Send it with your update

PATCH .../companies(<company-id>)/customers(<customer-id>)
Content-Type: application/json
If-Match: W/"JzE5OzEyMzQ1Njc4OTA7Jw=="

{
  "displayName": "Adatum Ltd"
}

Send only the fields you are changing. Anything you leave out keeps its value.

What the errors mean

ErrorCauseFix
BadRequest_InvalidToken: Could not validate the client concurrency tokenThe header is missing or malformed.Copy the whole value, including W/ and the quotes.
Request_EntityChanged: Another user has already changed the recordThe record changed after you read it.Read it again, check your change still makes sense, and retry with the new ETag.

What about If-Match: *?

A * means "whatever version it is", and Microsoft's own samples use it. It stops the error, but it also turns off the protection. If a colleague or another integration changed the record a moment ago, your update overwrites their change and nobody is told. It's fine for a quick test on a sandbox, but use the real ETag in anything that runs against live data.

The same thing in Ava

Ava remembers the ETag from each GET. Write If-Match: {{$etag}} and it sends the ETag of that same record, so there is nothing to copy. Update and Delete requests built from $metadata already include the header.

Sources