Power Pages Web API seems to ignore stale ETag / If-Match on PATCH

(1) Share

Report

Posted on by CU06021323-0

Hi,

I’m trying to implement safe concurrent editing in a custom Power Pages questionnaire

Multiple authenticated respondents may work on different parts of the same questionnaire at the same time, and I want to prevent silent overwrites if two users happen to edit the same Dataverse record.

The relevant custom Dataverse table is named: at_fq_answer

Optimistic concurrency is enabled for this table. I verified it in a model-driven app using:

Xrm.Utility
  .getEntityMetadata("at_fq_answer")
  .then(meta => {
    console.log(
      meta.IsOptimisticConcurrencyEnabled
    );
  });

----

With result: true, Power Pages Web API GET also returns ETags correctly.

For example: GET /_api/at_fq_answers(<id>)?$select=at_fq_answerid,at_value_text_short returned: @odata.etag: W/"5403465"

I then performed a PATCH using this exact ETag:

PATCH /_api/at_fq_answers(<id>)
If-Match: W/"5403465"
Content-Type: application/json

with payload:

{
  "at_value_text_short": "ETAG TEST - USER A"
}

The request succeeded: 204 No Content

A subsequent GET confirmed that the record was updated and that the ETag changed:

OLD ETAG: W/"5403465"
NEW ETAG: W/"5404447"

Then I deliberately sent another PATCH using the original stale ETag:

PATCH /_api/at_fq_answers(<id>)
If-Match: W/"5403465"
Content-Type: application/json

with a different payload:

{
  "at_value_text_short": "ETAG TEST - USER B STALE"
}

I expected: 412 Precondition Failed However, Power Pages returned: 204 No Content

and a final GET confirmed that the stale request actually overwrote the newer value: FINAL VALUE: ETAG TEST - USER B STALE,
So this does not look like only a response-code issue - the newer value was overwritten. I tested this using both: webapi.safeAjax and native: fetch() against the Power Pages /_api endpoint, with the same result.

I also verified in browser DevTools → Network that the stale If-Match header is actually present in the outgoing PATCH request:

:method: PATCH
:path: /_api/at_fq_answers(<id>)
content-type: application/json
if-match: W/"5403465"

So from the browser side, the version-specific If-Match header is definitely being sent.

My questions are:

Does the Power Pages Web API /_api endpoint officially support Dataverse optimistic concurrency using version-specific If-Match headers?

Is there any additional Power Pages site setting, Web API setting, table permission setting, or other configuration required for stale ETags to return 412 Precondition Failed?

Does the Power Pages Web API proxy intentionally strip, replace, or ignore version-specific If-Match values before forwarding the request to Dataverse?

If this behavior is not supported in Power Pages Web API, what is the recommended pattern for preventing lost updates in a multi-user Power Pages application?

The desired behavior is:

User A loads record with ETag W/"1" User B loads record with ETag W/"1" User A saves → succeeds → record becomes ETag W/"2" User B saves with If-Match: W/"1" → should fail with 412 → User A's changes should remain intact

Any confirmation on whether this scenario is supported through Power Pages /_api would be greatly appreciated.

Thanks!

Categories:

Design & build

All responses (2)

Answers (1)

Sort by

Verified answer

Valantis 7,415 Super User 2026 Season 2 on at

Like
a
(2)

Report
Copy link

Link copied!

Hi @CU06021323-0,

Found solid evidence for this. The portals Web API is explicitly documented as a subset of Dataverse Web API capabilities, same format, not the same feature set.https://learn.microsoft.com/en-us/power-pages/configure/web-api-overview

The official error handling reference lists every status code the portals Web API can return, 200, 204, 400, 404, 405, 413, 501, 503. 412 isn't in that list.

Compare that to the full Dataverse Web API, which has its own dedicated article documenting If-Match, If-None-Match, and 412 as a supported feature. The portals Web API docs have no equivalent article and no mention of ETag based conditional writes anywhere.
https://learn.microsoft.com/en-us/power-pages/configure/web-api-http-requests-handle-errors

https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/perform-conditional-operations-using-web-api

That matches what you're seeing exactly, the ETag comes through correctly on GET since that's driven by the table's optimistic concurrency setting itself, but the portal proxy layer doesn't enforce If-Match on write, it accepts the header and processes the update regardless. Not a missing setting, just not implemented in this subset.

Since server enforced conditional writes aren't available through _api, the practical pattern is building the version check yourself, server side. Store a version or modified timestamp field, and validate it inside a Dataverse plugin or Custom API triggered from the portal rather than relying on a direct PATCH.

A client side only check still leaves a race window between the check and the write, a plugin or Custom API gives you one atomic place to compare and reject.

Best regards,

Valantis ✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/ 💼 LinkedIn ▶️ YouTube
Suggested answer

11manish 4,676 Super User 2026 Season 2 on at

Like
a
(1)

Report
Copy link

Link copied!

Do not rely on If-Match through Power Pages /_api to prevent lost updates. Use a server-side concurrency mechanism or redesign the questionnaire data model to minimize concurrent updates to the same row.

Dataverse: Supports optimistic concurrency and stale-ETag detection.
Dataverse Web API: Supports If-Match and should return 412 Precondition Failed for a stale ETag.
Power Pages /_api: ️ Your reproducible test shows that the stale ETag is not being enforced. This should be treated as an unsupported/undocumented behavior or potential Power Pages Web API defect until Microsoft confirms otherwise.