Retrieve the Approval Requests on a Workflow
Changed onReturns a list of approval requests that have taken place on the workflow.
OAuth Scope required: public.workflows.readApprovals
Request
- Base URLhttps://ironcladapp.com/public/api/v1
- URLhttps://ironcladapp.com/public/api/v1/workflows/{id}/approval-requests
- AuthAPI key in header Authorization and OAuth 2Authorization code: https://ironcladapp.com/oauth/authorizeClient credentialsToken URL: https://ironcladapp.com/oauth/token scopes: public.workflows.readApprovals
Path parameters
The unique identifier or Ironclad ID of a workflow.
Query parameters
The page number used when paginating through a list of results.
A limit of the number of results to return.
An optional boolean parameter that adds additional information about the actor to each item in the response. Defaults to false.
An optional string parameter that specifies the type of approval requests and returns approval requests by role or user.
Headers
Denotes the actor of the request. When used, the API will take into account this user's permissions and access. This or x-as-user-id is required when the associated token was produced from the Client Credentials grant or with legacy bearer tokens on select endpoints. A token produced from the Authorization Code grant (which is already scoped to a user) may also use this header to act as a different user in the same company, provided the token carries the identity.users.impersonate scope and the token's own user has been granted the API User Impersonation permission. A request that sends this header without both never acts as the named user; depending on the company's configuration it either proceeds as the token's own user or is rejected with a 403. More information about permissions.
Denotes the actor of the request. When used, the API will take into account this user's permissions and access. This or x-as-user-email is required when the associated token was produced from the Client Credentials grant or with legacy bearer tokens on select endpoints. A token produced from the Authorization Code grant (which is already scoped to a user) may also use this header to act as a different user in the same company, provided the token carries the identity.users.impersonate scope and the token's own user has been granted the API User Impersonation permission. A request that sends this header without both never acts as the named user; depending on the company's configuration it either proceeds as the token's own user or is rejected with a 403. More information about permissions.
Response
200
Example response
{
"pageSize": 20,
"count": 42,
"list": [
{
"startTime": "2024-12-20T20:23:41.335Z",
"endTime": "2024-12-20T20:23:43.036Z",
"status": "Approved",
"actorId": "6334b636b9fb1eb6e76ada97",
"actorType": "User",
"actorDetails": {
"userName": "Cave Johnson",
"userEmail": "cave@aperturescience.com",
"userDepartment": "Legal"
},
"role": "approver58348a760b354ab3a986f56a74656c86",
"roleName": "CEO",
"duration": 1701,
"durationSeconds": 2,
"aggregateDuration": 1500,
"netRequestDurationSeconds": 11,
"netRequestDurationMinusCounterpartyTimeSeconds": 9,
"approvalType": "Workflow"
}
]
}Changes
- info
added the optional property
///to the response with the status - info
added the optional property
//to the response with the status - info
added the optional property
//to the response with the status - info
added the optional property
//to the response with the status
- info