Access Model Metadata Behavior: POST vs PATCH, Initialization State, and Search Delays
I’ve been building a PowerShell script to bulk-apply access model metadata (isCertifiable) to entitlements, access profiles, and roles sourced from IIQ custom objects and ran into a few behaviors I wanted to ask about.
Issue 1: POST works initially, but PATCH is required on subsequent runs
The documented approach for adding a metadata value is:
POST /v2025/entitlements/{id}/access-model-metadata/{key}/values/{value}
This works the first time. On subsequent runs, even after metadata has been removed, the same POST returns 400.1.1 Illegal update attempt.
The root cause: IDN appears to initialize the accessModelMetadata object on every entitlement, AP, and role when the attribute definition is created, leaving attributes: [] on all objects. Because that object exists, IDN rejects the POST as a duplicate modification.
Using JSON Patch against the object itself works in both states:
PATCH /v2025/entitlements/{id}
Content-Type: application/json-patch+json
[{
"op": "add",
"path": "/accessModelMetadata/attributes/-",
"value": {
"key": "entIsCertifiable",
"name": "isCertifiable",
"multiselect": false,
"status": "active",
"type": "custom",
"objectTypes": ["entitlement"],
"description": "...",
"values": [{ "value": "true", "name": "True", "status": "active" }]
}
}]
Note: a minimal body with only key and value returns 500 Internal Server Error; the full attribute schema object is required.
Is the initialized-state behavior intentional? Does attributes: [] always mean the same thing regardless of whether metadata was ever set or was set and then cleared?
Issue 2: Search index delay after metadata changes
After applying or removing metadata values, GET /v2025/search queries filtering on accessModelMetadata.attributes.key do not reflect the change immediately, while GET /v2025/entitlements/{id} returns the correct state right away.
For bulk scripts using search to pre-fetch which objects already have metadata set, stale search results can cause the script to attempt re-applying values that were already set, triggering the 400.1.1 above. The workaround is to fetch each object individually before applying rather than relying on a bulk search pre-check. Is there an expected propagation window, or a way to get consistent reads from search?
Issue 3: Attribute definition deletion takes ~5 minutes
When deleting an attribute definition and attempting to recreate it, GET /v2025/access-model-metadata/attributes/{key} returns a "status": "deleting" state for roughly 4-5 minutes. Attempting to create a new definition with the same key during that window fails. Is this the expected behavior, and is 5 minutes a reasonable upper bound to poll against?
Happy to share the full script if helpful.