If you’ve just created a requestable role in ISC and tried to test it immediately, you’ve probably noticed something annoying. It doesn’t show up in the Request Center.
Wait a bit. Still nothing. Eventually it will appear. This isn’t a configuration issue. It’s indexing. Roles and access profiles need to be indexed before they show up in the UI. The time this takes varies. It’s often quick, but depending on tenant load it can run long enough to block you. That delay is fine for end users, but it gets in the way when you’re actively building and validating.
In our case, this came up during pipeline deployments. We needed to validate roles immediately after deployment before handing off to UAT. Waiting for the UI to catch up wasn’t workable, so instead of waiting, we stopped using the UI for this step.
Prerequisites
Before using the API-based approach, make sure the following are in place:
- You have a Personal Access Token (PAT) with sufficient permissions to submit access requests. See the Authentication section of the ISC API documentation for how to generate one.
- The role or access profile you want to test already exists in ISC and has been saved.
- The role or access profile must be enabled and marked as requestable. If it is not, the API will return a misleading “does not exist” error even though the item is visible in the UI.
- You know the name of the test identity you want to request access for (or have a way to look it up).
- You have a REST client available — curl, Postman, or a scripting language of your choice.
Access Request API
The Access Request API doesn’t depend on indexing. If you already know the IDs, you can trigger the request directly. The same steps work for both roles and access profiles; the only difference is the endpoint you use to retrieve the item ID and the type field in the request payload.
Step 1: Get the identity ID
Look up the identity you want to request access for by name:
GET https://<tenant>.api.identitynow.com/v2026/identities?filters=name eq "test.user"
The filters value is shown unencoded for readability. In an actual request, the spaces and quotes need to be URL-encoded (name%20eq%20%22test.user%22). Clients like Postman and curl handle this for you, but if you’re building the URL by hand, encode it.
Response:
{
"id": "<IdentityID>",
"name": "test.user"
}
Step 2: Get the role or access profile ID
For a role:
GET https://<tenant>.api.identitynow.com/v2026/roles?filters=name eq "Test_Role_Read"
Response:
{
"id": "<RoleID>",
"name": "Test_Role_Read"
}
For an access profile, use the same pattern with the /access-profiles endpoint:
GET https://<tenant>.api.identitynow.com/v2026/access-profiles?filters=name eq "Test_AP_Read"
Response:
{
"id": "<AccessProfileID>",
"name": "Test_AP_Read"
}
Step 3: Submit the access request
Once you have both IDs, submit the request. Set "type" to "ROLE" or "ACCESS_PROFILE" depending on the item type:
POST https://<tenant>.api.identitynow.com/v2026/access-requests
Payload:
{
"requestedFor": [
"<IdentityID_1>",
"<IdentityID_2>"
],
"requestedItems": [
{
"id": "<RoleID>",
"type": "ROLE",
"comment": "Pipeline validation request"
}
],
"requestType": "GRANT_ACCESS"
}
Or via curl:
curl --request POST 'https://<tenant>.api.identitynow.com/v2026/access-requests' \
--header 'Authorization: Bearer <PAT_TOKEN>' \
--header 'Content-Type: application/json' \
--data-raw '{
"requestedFor": ["<IdentityID_1>", "<IdentityID_2>"],
"requestedItems": [{ "id": "<RoleID>", "type": "ROLE" }],
"requestType": "GRANT_ACCESS"
}'
Step 4: Check the response
A successful submission returns 202 Accepted. The body contains one request object per identity, each with the accessRequestIds you’ll use to track status:
{
"newRequests": [
{
"requestedFor": "<IdentityID_1>",
"accessRequestIds": ["<AccessRequestID_1>"]
},
{
"requestedFor": "<IdentityID_2>",
"accessRequestIds": ["<AccessRequestID_2>"]
}
]
}
Validating the Request
A submitted request and delivered access aren’t the same thing. Access requests are processed asynchronously, so a 202 on submission only means the request was queued, but it doesn’t confirm anything provisioned. Validation is two checks: confirm the request reached a terminal state, then confirm the access actually landed on the identity.
1. Check the request status. Using an accessRequestId from Step 4, poll the status endpoint. There’s no top-level accessRequestId query parameter. You will need to filter for it through the filters parameter instead:
GET https://<tenant>.api.identitynow.com/v2026/access-request-status?filters=accessRequestId eq "<AccessRequestID>"
This returns 200 OK. Look at the "state" field. While the request is still in progress it reports "EXECUTING", and if approval workflows are configured it stays there until approved. Once it reaches a terminal state the request has finished.
2. Confirm the assigned access. To verify the role or access profile actually landed on the identity, query the identities search index, which returns an access[] array with roles and access profiles as first-class items:
POST https://<tenant>.api.identitynow.com/v2026/search
{
"indices": ["identities"],
"query": { "query": "id:\"<IdentityID>\"" }
}
In the response, look in access[] for an entry whose type is ROLE (or ACCESS_PROFILE) and whose name or id matches what you requested. This confirms the access is assigned, not just that the request closed.
Note: If the role or access profile is not enabled, the API returns
Role with id <RoleID> does not exist. This error is misleading — the item may be visible in the UI and retrievable via GET, but the access request engine treats disabled or non-requestable items as non-existent. If you hit this, confirm the item is set to Enabled and marked as Requestable before testing.
Fitting This Into a Pipeline
Once you start using this approach, testing becomes cleaner and more predictable. Instead of waiting on indexing:
- Deploy the role or access profile.
- Trigger the request via API using the steps above.
- Poll the request status until it reaches a terminal state.
- Confirm the access on the identity via the search index.
This fits naturally into CI/CD pipelines, letting you validate access end-to-end as part of deployment rather than treating it as a separate manual step.
It’s also worth noting that this approach does not bypass governance. Approval flows, policies, and audit trails behave exactly the same way as they would through the Request Center.
One caveat worth revisiting periodically: this is a workaround for a current gap in how quickly the GUI reflects newly created access items. ISC’s interface continues to evolve, so it’s worth checking whether indexing latency has improved enough that the UI path is workable again before assuming the API approach is still necessary.
Summary
The Access Request API accepts item IDs directly, so UI indexing is not a prerequisite for testing. By retrieving the identity ID and role or access profile ID immediately after creation, you can submit and validate access requests without any indexing delay making it a practical fit for both ad hoc validation and automated deployment pipelines.