Does Microsoft Graph v1.0 support If-Match for application keyCredentials updates?

Microsoft Graph v1.0 does not document a supported ETag/If-Match contract for PATCH /applications/{id}, so it cannot be used as a supported atomic compare-and-swap update for keyCredentials.

Endpoint behavior

The Update application endpoint:

• Allows keyCredentials in the PATCH body.
• Documents only Authorization and Content-Type request headers—not If-Match.
• Returns 204 No Content after a successful update.
• Does not document 412 Precondition Failed for a stale application version. ^1^

Consequently, there is no documented application ETag that can be retrieved and passed back for optimistic concurrency. The Get application endpoint documents a 200 OK application response and only the Authorization request header; it does not identify an ETag response header or an @odata.etag field. ^2^

The application resource schema likewise lists keyCredentials but no etag, @odata.etag, changeKey, or other concurrency-token property. ^3^

Therefore, none of the following is part of the documented v1.0 contract:

GET /v1.0/applications/{id}
# No documented ETag token for this resource

PATCH /v1.0/applications/{id}
If-Match: "previous-value"
Content-Type: application/json

{
  "keyCredentials": [ ... ]
}

In particular, client code should not rely on a stale If-Match producing 412 Precondition Failed or preserving a newer keyCredentials list. The available documentation does not guarantee that behavior.

Adding the first certificate

Adding or replacing certificates through PATCH /applications/{id} is supported, including when the current keyCredentials collection is empty. The update documentation defines keyCredentials as an updatable, non-nullable collection. ^1^

When constructing the replacement collection:

1. Read the current application with:

      GET https://graph.microsoft.com/v1.0/applications/{id}?$select=id,keyCredentials
      Authorization: Bearer {token}
   

2. Merge the new public certificate into the returned collection.
3. PATCH the complete intended collection:

      PATCH https://graph.microsoft.com/v1.0/applications/{id}
      Authorization: Bearer {token}
      Content-Type: application/json
   
      {
        "keyCredentials": [
          {
            "type": "AsymmetricX509Cert",
            "usage": "Verify",
            "key": "{base64-encoded-public-certificate}"
          }
        ]
      }
   

The certificate’s key is Base64-encoded certificate data; only the public certificate should be supplied. ^4^

This PATCH is atomic as an individual HTTP update, but it is not a documented conditional atomic update relative to the preceding GET. Two writers performing read-modify-write can overwrite one another’s collection changes.

Why addKey does not solve the empty-list case

The POST /applications/{id}/addKey action is intended for automated key rolling and requires proof of possession signed by an existing valid application certificate. An application with no existing valid certificate cannot use that action; Microsoft explicitly directs that case to Update application instead. ^5^

For workloads requiring strict concurrency, serialize credential updates outside Graph—for example, through a single writer or a lock/version record in a data store that supports conditional writes—then re-read the application after PATCH and verify the resulting keyCredentials set. That verification detects a conflict but cannot make the Graph read-modify-write sequence atomic.

References

1. Update application
2. Get application
3. application resource type
4. keyCredential resource type
5. application: addKey