- okta.accessRequests.request.read
Retrieves a request belonging to the authenticated requester
curl -i -X GET \
https://okta-subdomain.pixtulate.com/governance/api/v2/my/catalogs/default/entries/cenp2rjyxK1Js2Fc41d5/requests/reqp1pmpjhVdGEcVK1d5A successful get request response
The id of the Okta user who created the resource
The ISO 8601 formatted date and time when the resource was created
The ISO 8601 formatted date and time when the object was last updated
The id of the Okta user who last updated the object
The status of the request
The date the request was resolved. The property may transition from having a value to null if the request is reopened.
The grant status of the request
The date the approved access was granted. Only set if request.status is APPROVED.
The revocation status of the request
The date the granted access was revoked. Only set if request.grantStatus is GRANTED and request.revocationStatus is REVOKED.
How long the requester retains access after their request is approved and fulfilled.
Specified in ISO 8601 duration format.
Only single time unit ISO 8601 duration formats (D, H, M) are supported for units (days, hours, minutes).
| Unit | Example |
|---|---|
| D, days | P40D |
| H, hours | PT65H |
| M, minutes | PT90M |
Note: Mixes of units, as well as month/year/week designations, aren't supported. For example,
P40DT65H,P40M,P1W, andP1Yaren't supported.
The date the granted access is scheduled for recovation. Only set if request.accessDuration exists, and request.grantStatus is GRANTED.
The requester input fields required by the approval system.
Note: The fields required are determined by the approval system.
For the Okta approval system, the required fields are defined in the approval sequence. Ensure that the requester input fields match up with this definition to avoid request approval flow failure.
For external approval systems, the requester input fields are for recording purposes only and do not affect the approval process.
- When a request is just submitted |tooltip| Submitted requests can't yet have an `approvalSequenceId` or `requestConditionId`.
- When request becomes PENDING |tooltip| PENDING requests have a matched approval sequence and condition, but do not yet have any approvals or fulfillment.
- When creating the request is rejected |tooltip| Requests may be rejected for several reasons: - If a request can't be matched to any request condition, it will lack an approval sequence and matched condition. - If a request does match a request condition but fails validation, it will have an approval sequence and matched condition, yet still be rejected due to validation failure.
- When request becomes DENIED |tooltip| DENIED requests have a matched approval sequence and condition, and at least one approval which was denied.
- When request becomes APPROVED |tooltip| APPROVED requests have a matched approval sequence and condition, and either no approvals, or one more APPROVED approvals. An approved request's grant status starts in PENDING status.
- When request becomes APPROVED from assigned delegate |tooltip| APPROVED requests have a matched approval sequence and condition, and either no approvals, or one more APPROVED approvals. An approved request's grant status starts in PENDING status.
- When request becomes APPROVED from assigned escalated user |tooltip| APPROVED requests have a matched approval sequence and condition, and either no approvals, or one more APPROVED approvals. An approved request's grant status starts in PENDING status.
- When the request is approved, the access grant is successful |tooltip| When an approved request has access granted, and there is no access duration.
- When the request is approved, the access grant has failed |tooltip| When a request is approved, but the process of granting the access to the requested resource is failed.
- When the request is approved, granting access has to be manual |tooltip| When an approved request has access granted, and there is no access duration.
- When request was requested on behalf of another requester |tooltip| Requests that were requested by another requester will have a `OKTA_REQUESTED_FOR` `requesterFieldValues`. Whose user will match the `requestedFor` OKTA_USER
- When request is created using client credentials token |tooltip| Request created using client credentials authentication with `UNKNOWN` principal type in `requestedBy` field.
- When existing request has risk assessment
{ "id": "req42kjDgk1EubTwo0g4", "created": "2019-08-24T14:15:22Z", "createdBy": "00ub0oNGTSWTBKOLGLNR", "lastUpdated": "2022-05-05T14:15:22Z", "lastUpdatedBy": "00ub0oNGTSWTBKOLGLNR", "status": "SUBMITTED", "requestedBy": { "type": "OKTA_USER", "externalId": "00ub0oNGTSWTBKOLGLNR" }, "requestedFor": { "type": "OKTA_USER", "externalId": "00ub0oNGTSWTBKOLGLNR" }, "requesterFieldValues": [ { … } ], "requested": { "entryId": "cenb0oADRXTBKOLGLNR", "resourceId": "0oafxqCAJWWGELFTYASJ", "resourceType": "APPLICATION", "accessScopeId": "0oafxqCAJWWGELFTYASJ", "accessScopeType": "APPLICATION" }, "requestApproval": { "type": "OKTA", "providerName": "Okta Access Requests", "providerDescription": "Okta Access Requests", "permalinkId": 1 }, "_links": { "catalogEntry": { … }, "self": { … } } }