sailpoint-api-client 1.8.56 → 1.8.58
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/beta/README.md +2 -2
- package/beta/api.ts +35 -11
- package/beta/common.ts +2 -2
- package/beta/package.json +1 -1
- package/dist/beta/api.d.ts +35 -11
- package/dist/beta/api.js +8 -8
- package/dist/beta/api.js.map +1 -1
- package/dist/beta/common.js +2 -2
- package/dist/nerm/common.js +2 -2
- package/dist/nermv2025/common.js +2 -2
- package/dist/v2024/api.d.ts +32 -8
- package/dist/v2024/api.js +6 -6
- package/dist/v2024/api.js.map +1 -1
- package/dist/v2024/common.js +2 -2
- package/dist/v2025/api.d.ts +32 -8
- package/dist/v2025/api.js +6 -6
- package/dist/v2025/api.js.map +1 -1
- package/dist/v2025/common.js +2 -2
- package/dist/v2026/api.d.ts +32 -8
- package/dist/v2026/api.js +6 -6
- package/dist/v2026/api.js.map +1 -1
- package/dist/v2026/common.js +2 -2
- package/dist/v3/api.d.ts +26 -8
- package/dist/v3/api.js +6 -6
- package/dist/v3/api.js.map +1 -1
- package/dist/v3/common.js +2 -2
- package/nerm/README.md +2 -2
- package/nerm/common.ts +2 -2
- package/nerm/package.json +1 -1
- package/nermv2025/README.md +2 -2
- package/nermv2025/common.ts +2 -2
- package/nermv2025/package.json +1 -1
- package/package.json +1 -1
- package/v2024/README.md +2 -2
- package/v2024/api.ts +32 -8
- package/v2024/common.ts +2 -2
- package/v2024/package.json +1 -1
- package/v2025/README.md +2 -2
- package/v2025/api.ts +32 -8
- package/v2025/common.ts +2 -2
- package/v2025/package.json +1 -1
- package/v2026/README.md +2 -2
- package/v2026/api.ts +32 -8
- package/v2026/common.ts +2 -2
- package/v2026/package.json +1 -1
- package/v3/README.md +2 -2
- package/v3/api.ts +26 -8
- package/v3/common.ts +2 -2
- package/v3/package.json +1 -1
package/dist/v2024/common.js
CHANGED
|
@@ -250,12 +250,12 @@ var createRequestFunction = function (axiosArgs, globalAxios, BASE_PATH, configu
|
|
|
250
250
|
if (axios === void 0) { axios = globalAxios; }
|
|
251
251
|
if (basePath === void 0) { basePath = BASE_PATH; }
|
|
252
252
|
(0, axios_retry_1.default)(axios, configuration.retriesConfig);
|
|
253
|
-
var userAgent = "SailPoint-SDK-TypeScript/1.8.
|
|
253
|
+
var userAgent = "SailPoint-SDK-TypeScript/1.8.58";
|
|
254
254
|
if ((configuration === null || configuration === void 0 ? void 0 : configuration.consumerIdentifier) && (configuration === null || configuration === void 0 ? void 0 : configuration.consumerVersion)) {
|
|
255
255
|
userAgent += " (".concat(configuration.consumerIdentifier, "/").concat(configuration.consumerVersion, ")");
|
|
256
256
|
}
|
|
257
257
|
userAgent += " (".concat(process.platform, "; ").concat(process.arch, ") Node/").concat(process.versions.node, " (openapi-generator/7.12.0)");
|
|
258
|
-
var headers = __assign(__assign(__assign({}, axiosArgs.axiosOptions.headers), { 'X-SailPoint-SDK': 'typescript-1.8.
|
|
258
|
+
var headers = __assign(__assign(__assign({}, axiosArgs.axiosOptions.headers), { 'X-SailPoint-SDK': 'typescript-1.8.58' }), { 'User-Agent': userAgent });
|
|
259
259
|
if (!configuration.experimental && ("X-SailPoint-Experimental" in headers)) {
|
|
260
260
|
throw new Error("You are using Experimental APIs. Set configuration.experimental = True to enable these APIs in the SDK.");
|
|
261
261
|
}
|
package/dist/v2025/api.d.ts
CHANGED
|
@@ -2177,6 +2177,12 @@ export interface AccessRequestAdminItemStatusV2025 {
|
|
|
2177
2177
|
* @memberof AccessRequestAdminItemStatusV2025
|
|
2178
2178
|
*/
|
|
2179
2179
|
'description'?: string | null;
|
|
2180
|
+
/**
|
|
2181
|
+
* When the role access is scheduled for provisioning.
|
|
2182
|
+
* @type {string}
|
|
2183
|
+
* @memberof AccessRequestAdminItemStatusV2025
|
|
2184
|
+
*/
|
|
2185
|
+
'startDate'?: string | null;
|
|
2180
2186
|
/**
|
|
2181
2187
|
* When the role access is scheduled for removal.
|
|
2182
2188
|
* @type {string}
|
|
@@ -2516,6 +2522,12 @@ export interface AccessRequestItemV2025 {
|
|
|
2516
2522
|
'clientMetadata'?: {
|
|
2517
2523
|
[key: string]: string;
|
|
2518
2524
|
};
|
|
2525
|
+
/**
|
|
2526
|
+
* The date and time the role or access profile or entitlement is/will be provisioned to the specified identity. Also known as the sunrise date. * Specify a date-time in the future. * This date-time can be used to indicate date-time when access item will be provisioned on the identity account. A GRANT_ACCESS request can use startDate to specify when to schedule provisioning of access item for an identity/account & a MODIFY_ACCESS request can use startDate to change the provisioning date-time of already assigned access item. But REVOKE_ACCESS request can not have startDate field. You can change the sunrise date in requests for yourself or others you are authorized to request for. * If the startDate is in the past, then the provisioning will be processed as soon as possible, but no guarantees can be made about when the provisioning will occur. If the startDate is in the future, then the provisioning will be scheduled to occur on that date and time. If no startDate is provided, then the provisioning will be processed as soon as possible.
|
|
2527
|
+
* @type {string}
|
|
2528
|
+
* @memberof AccessRequestItemV2025
|
|
2529
|
+
*/
|
|
2530
|
+
'startDate'?: string;
|
|
2519
2531
|
/**
|
|
2520
2532
|
* The date and time the role or access profile or entitlement is no longer assigned to the specified identity. Also known as the expiration date. * Specify a date-time in the future. * The current SLA for the deprovisioning is 24 hours. * This date-time can be used to change the duration of an existing access item assignment for the specified identity. A GRANT_ACCESS request can extend duration or even remove an expiration date, and either a GRANT_ACCESS or REVOKE_ACCESS request can reduce duration or add an expiration date where one has not previously been present. You can change the expiration date in requests for yourself or others you are authorized to request for.
|
|
2521
2533
|
* @type {string}
|
|
@@ -3186,7 +3198,7 @@ export interface AccessRequestV2025 {
|
|
|
3186
3198
|
[key: string]: string;
|
|
3187
3199
|
};
|
|
3188
3200
|
/**
|
|
3189
|
-
* Additional submit data structure with requestedFor containing requestedItems allowing distinction for each request item and Identity. * Can only be used when \'requestedFor\' and \'requestedItems\' are not separately provided * Adds ability to specify which account the user wants the access on, in case they have multiple accounts on a source * Allows the ability to request items with different remove dates * Also allows different combinations of request items and identities in the same request * Only for use in GRANT_ACCESS type requests
|
|
3201
|
+
* Additional submit data structure with requestedFor containing requestedItems allowing distinction for each request item and Identity. * Can only be used when \'requestedFor\' and \'requestedItems\' are not separately provided * Adds ability to specify which account the user wants the access on, in case they have multiple accounts on a source * Allows the ability to request items with different start dates * Allows the ability to request items with different remove dates * Also allows different combinations of request items and identities in the same request * Only for use in GRANT_ACCESS type requests
|
|
3190
3202
|
* @type {Array<RequestedForDtoRefV2025>}
|
|
3191
3203
|
* @memberof AccessRequestV2025
|
|
3192
3204
|
*/
|
|
@@ -36017,6 +36029,12 @@ export interface RequestedItemDtoRefV2025 {
|
|
|
36017
36029
|
'clientMetadata'?: {
|
|
36018
36030
|
[key: string]: string;
|
|
36019
36031
|
};
|
|
36032
|
+
/**
|
|
36033
|
+
* The date and time the role or access profile or entitlement is/will be provisioned to the specified identity. Also known as the sunrise date. * Specify a date-time in the future. * This date-time can be used to indicate date-time when access item will be provisioned on the identity account. A GRANT_ACCESS request can use startDate to specify when to schedule provisioning of access item for an identity/account & a MODIFY_ACCESS request can use startDate to change the provisioning date-time of already assigned access item. But REVOKE_ACCESS request can not have startDate field. You can change the sunrise date in requests for yourself or others you are authorized to request for. * If the startDate is in the past, then the provisioning will be processed as soon as possible, but no guarantees can be made about when the provisioning will occur. If the startDate is in the future, then the provisioning will be scheduled to occur on that date and time. If no startDate is provided, then the provisioning will be processed as soon as possible.
|
|
36034
|
+
* @type {string}
|
|
36035
|
+
* @memberof RequestedItemDtoRefV2025
|
|
36036
|
+
*/
|
|
36037
|
+
'startDate'?: string;
|
|
36020
36038
|
/**
|
|
36021
36039
|
* The date and time the role or access profile or entitlement is no longer assigned to the specified identity. Also known as the expiration date. * Specify a date-time in the future. * The current SLA for the deprovisioning is 24 hours. * This date-time can be used to change the duration of an existing access item assignment for the specified identity. A GRANT_ACCESS request can extend duration or even remove an expiration date, and either a GRANT_ACCESS or REVOKE_ACCESS request can reduce duration or add an expiration date where one has not previously been present. You can change the expiration date in requests for yourself or others you are authorized to request for.
|
|
36022
36040
|
* @type {string}
|
|
@@ -36337,6 +36355,12 @@ export interface RequestedItemStatusV2025 {
|
|
|
36337
36355
|
* @memberof RequestedItemStatusV2025
|
|
36338
36356
|
*/
|
|
36339
36357
|
'description'?: string | null;
|
|
36358
|
+
/**
|
|
36359
|
+
* When the role access is scheduled for provisioning.
|
|
36360
|
+
* @type {string}
|
|
36361
|
+
* @memberof RequestedItemStatusV2025
|
|
36362
|
+
*/
|
|
36363
|
+
'startDate'?: string | null;
|
|
36340
36364
|
/**
|
|
36341
36365
|
* When the role access is scheduled for removal.
|
|
36342
36366
|
* @type {string}
|
|
@@ -53358,7 +53382,7 @@ export declare const AccessRequestsV2025ApiAxiosParamCreator: (configuration?: C
|
|
|
53358
53382
|
*/
|
|
53359
53383
|
closeAccessRequest: (closeAccessRequestV2025: CloseAccessRequestV2025, axiosOptions?: RawAxiosRequestConfig) => Promise<RequestArgs>;
|
|
53360
53384
|
/**
|
|
53361
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
53385
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `startDate` to set or alter a sunrise date-time on an assignment. The startDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunrise date and its yet to be provisioned, you can also submit a request without a `startDate` to request immediate provisioning after approval. * If a `startDate` is specified, then the requested role, access profile, or entitlement will be provisioned on that date and time. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You cannot specify a \'startDate\' in a REVOKE_ACCESS request, as startDate is only applicable for GRANT_ACCESS requests to indicate when the access should be provisioned, and it does not make sense in the context of revoking access. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
53362
53386
|
* @summary Submit access request
|
|
53363
53387
|
* @param {AccessRequestV2025} accessRequestV2025
|
|
53364
53388
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -53410,7 +53434,7 @@ export declare const AccessRequestsV2025ApiAxiosParamCreator: (configuration?: C
|
|
|
53410
53434
|
* @param {boolean} [count] If this is true, the *X-Total-Count* response header populates with the number of results that would be returned if limit and offset were ignored.
|
|
53411
53435
|
* @param {number} [limit] Max number of results to return.
|
|
53412
53436
|
* @param {number} [offset] Offset into the full result set. Usually specified with *limit* to paginate through the results. Defaults to 0 if not specified.
|
|
53413
|
-
* @param {string} [filters] Filter results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#filtering-results) Filtering is supported for the following fields and operators: **accountActivityItemId**: *eq, in, ge, gt, le, lt, ne, isnull, sw* **accessRequestId**: *in* **status**: *in, eq, ne* **created**: *eq, in, ge, gt, le, lt, ne, isnull, sw*
|
|
53437
|
+
* @param {string} [filters] Filter results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#filtering-results) Filtering is supported for the following fields and operators: **accountActivityItemId**: *eq, in, ge, gt, le, lt, ne, isnull, sw* **accessRequestId**: *in, eq, ne, ge, gt, le, lt, sw* **status**: *in, eq, ne* **created**: *eq, in, ge, gt, le, lt, ne, isnull, sw*
|
|
53414
53438
|
* @param {string} [sorters] Sort results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#sorting-results) Sorting is supported for the following fields: **created, modified, accountActivityItemId, name, accessRequestId**
|
|
53415
53439
|
* @param {string} [requestState] Filter the results by the state of the request. The only valid value is *EXECUTING*.
|
|
53416
53440
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -53474,7 +53498,7 @@ export declare const AccessRequestsV2025ApiFp: (configuration?: Configuration) =
|
|
|
53474
53498
|
*/
|
|
53475
53499
|
closeAccessRequest(closeAccessRequestV2025: CloseAccessRequestV2025, axiosOptions?: RawAxiosRequestConfig): Promise<(axios?: AxiosInstance, basePath?: string) => AxiosPromise<object>>;
|
|
53476
53500
|
/**
|
|
53477
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
53501
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `startDate` to set or alter a sunrise date-time on an assignment. The startDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunrise date and its yet to be provisioned, you can also submit a request without a `startDate` to request immediate provisioning after approval. * If a `startDate` is specified, then the requested role, access profile, or entitlement will be provisioned on that date and time. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You cannot specify a \'startDate\' in a REVOKE_ACCESS request, as startDate is only applicable for GRANT_ACCESS requests to indicate when the access should be provisioned, and it does not make sense in the context of revoking access. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
53478
53502
|
* @summary Submit access request
|
|
53479
53503
|
* @param {AccessRequestV2025} accessRequestV2025
|
|
53480
53504
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -53526,7 +53550,7 @@ export declare const AccessRequestsV2025ApiFp: (configuration?: Configuration) =
|
|
|
53526
53550
|
* @param {boolean} [count] If this is true, the *X-Total-Count* response header populates with the number of results that would be returned if limit and offset were ignored.
|
|
53527
53551
|
* @param {number} [limit] Max number of results to return.
|
|
53528
53552
|
* @param {number} [offset] Offset into the full result set. Usually specified with *limit* to paginate through the results. Defaults to 0 if not specified.
|
|
53529
|
-
* @param {string} [filters] Filter results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#filtering-results) Filtering is supported for the following fields and operators: **accountActivityItemId**: *eq, in, ge, gt, le, lt, ne, isnull, sw* **accessRequestId**: *in* **status**: *in, eq, ne* **created**: *eq, in, ge, gt, le, lt, ne, isnull, sw*
|
|
53553
|
+
* @param {string} [filters] Filter results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#filtering-results) Filtering is supported for the following fields and operators: **accountActivityItemId**: *eq, in, ge, gt, le, lt, ne, isnull, sw* **accessRequestId**: *in, eq, ne, ge, gt, le, lt, sw* **status**: *in, eq, ne* **created**: *eq, in, ge, gt, le, lt, ne, isnull, sw*
|
|
53530
53554
|
* @param {string} [sorters] Sort results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#sorting-results) Sorting is supported for the following fields: **created, modified, accountActivityItemId, name, accessRequestId**
|
|
53531
53555
|
* @param {string} [requestState] Filter the results by the state of the request. The only valid value is *EXECUTING*.
|
|
53532
53556
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -53590,7 +53614,7 @@ export declare const AccessRequestsV2025ApiFactory: (configuration?: Configurati
|
|
|
53590
53614
|
*/
|
|
53591
53615
|
closeAccessRequest(requestParameters: AccessRequestsV2025ApiCloseAccessRequestRequest, axiosOptions?: RawAxiosRequestConfig): AxiosPromise<object>;
|
|
53592
53616
|
/**
|
|
53593
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
53617
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `startDate` to set or alter a sunrise date-time on an assignment. The startDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunrise date and its yet to be provisioned, you can also submit a request without a `startDate` to request immediate provisioning after approval. * If a `startDate` is specified, then the requested role, access profile, or entitlement will be provisioned on that date and time. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You cannot specify a \'startDate\' in a REVOKE_ACCESS request, as startDate is only applicable for GRANT_ACCESS requests to indicate when the access should be provisioned, and it does not make sense in the context of revoking access. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
53594
53618
|
* @summary Submit access request
|
|
53595
53619
|
* @param {AccessRequestsV2025ApiCreateAccessRequestRequest} requestParameters Request parameters.
|
|
53596
53620
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -53853,7 +53877,7 @@ export interface AccessRequestsV2025ApiListAdministratorsAccessRequestStatusRequ
|
|
|
53853
53877
|
*/
|
|
53854
53878
|
readonly offset?: number;
|
|
53855
53879
|
/**
|
|
53856
|
-
* Filter results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#filtering-results) Filtering is supported for the following fields and operators: **accountActivityItemId**: *eq, in, ge, gt, le, lt, ne, isnull, sw* **accessRequestId**: *in* **status**: *in, eq, ne* **created**: *eq, in, ge, gt, le, lt, ne, isnull, sw*
|
|
53880
|
+
* Filter results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#filtering-results) Filtering is supported for the following fields and operators: **accountActivityItemId**: *eq, in, ge, gt, le, lt, ne, isnull, sw* **accessRequestId**: *in, eq, ne, ge, gt, le, lt, sw* **status**: *in, eq, ne* **created**: *eq, in, ge, gt, le, lt, ne, isnull, sw*
|
|
53857
53881
|
* @type {string}
|
|
53858
53882
|
* @memberof AccessRequestsV2025ApiListAdministratorsAccessRequestStatus
|
|
53859
53883
|
*/
|
|
@@ -53947,7 +53971,7 @@ export declare class AccessRequestsV2025Api extends BaseAPI {
|
|
|
53947
53971
|
*/
|
|
53948
53972
|
closeAccessRequest(requestParameters: AccessRequestsV2025ApiCloseAccessRequestRequest, axiosOptions?: RawAxiosRequestConfig): Promise<import("axios").AxiosResponse<object, any>>;
|
|
53949
53973
|
/**
|
|
53950
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
53974
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `startDate` to set or alter a sunrise date-time on an assignment. The startDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunrise date and its yet to be provisioned, you can also submit a request without a `startDate` to request immediate provisioning after approval. * If a `startDate` is specified, then the requested role, access profile, or entitlement will be provisioned on that date and time. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You cannot specify a \'startDate\' in a REVOKE_ACCESS request, as startDate is only applicable for GRANT_ACCESS requests to indicate when the access should be provisioned, and it does not make sense in the context of revoking access. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
53951
53975
|
* @summary Submit access request
|
|
53952
53976
|
* @param {AccessRequestsV2025ApiCreateAccessRequestRequest} requestParameters Request parameters.
|
|
53953
53977
|
* @param {*} [axiosOptions] Override http request option.
|
package/dist/v2025/api.js
CHANGED
|
@@ -7453,7 +7453,7 @@ var AccessRequestsV2025ApiAxiosParamCreator = function (configuration) {
|
|
|
7453
7453
|
});
|
|
7454
7454
|
},
|
|
7455
7455
|
/**
|
|
7456
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
7456
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `startDate` to set or alter a sunrise date-time on an assignment. The startDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunrise date and its yet to be provisioned, you can also submit a request without a `startDate` to request immediate provisioning after approval. * If a `startDate` is specified, then the requested role, access profile, or entitlement will be provisioned on that date and time. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You cannot specify a \'startDate\' in a REVOKE_ACCESS request, as startDate is only applicable for GRANT_ACCESS requests to indicate when the access should be provisioned, and it does not make sense in the context of revoking access. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
7457
7457
|
* @summary Submit access request
|
|
7458
7458
|
* @param {AccessRequestV2025} accessRequestV2025
|
|
7459
7459
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -7713,7 +7713,7 @@ var AccessRequestsV2025ApiAxiosParamCreator = function (configuration) {
|
|
|
7713
7713
|
* @param {boolean} [count] If this is true, the *X-Total-Count* response header populates with the number of results that would be returned if limit and offset were ignored.
|
|
7714
7714
|
* @param {number} [limit] Max number of results to return.
|
|
7715
7715
|
* @param {number} [offset] Offset into the full result set. Usually specified with *limit* to paginate through the results. Defaults to 0 if not specified.
|
|
7716
|
-
* @param {string} [filters] Filter results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#filtering-results) Filtering is supported for the following fields and operators: **accountActivityItemId**: *eq, in, ge, gt, le, lt, ne, isnull, sw* **accessRequestId**: *in* **status**: *in, eq, ne* **created**: *eq, in, ge, gt, le, lt, ne, isnull, sw*
|
|
7716
|
+
* @param {string} [filters] Filter results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#filtering-results) Filtering is supported for the following fields and operators: **accountActivityItemId**: *eq, in, ge, gt, le, lt, ne, isnull, sw* **accessRequestId**: *in, eq, ne, ge, gt, le, lt, sw* **status**: *in, eq, ne* **created**: *eq, in, ge, gt, le, lt, ne, isnull, sw*
|
|
7717
7717
|
* @param {string} [sorters] Sort results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#sorting-results) Sorting is supported for the following fields: **created, modified, accountActivityItemId, name, accessRequestId**
|
|
7718
7718
|
* @param {string} [requestState] Filter the results by the state of the request. The only valid value is *EXECUTING*.
|
|
7719
7719
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -8019,7 +8019,7 @@ var AccessRequestsV2025ApiFp = function (configuration) {
|
|
|
8019
8019
|
});
|
|
8020
8020
|
},
|
|
8021
8021
|
/**
|
|
8022
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
8022
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `startDate` to set or alter a sunrise date-time on an assignment. The startDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunrise date and its yet to be provisioned, you can also submit a request without a `startDate` to request immediate provisioning after approval. * If a `startDate` is specified, then the requested role, access profile, or entitlement will be provisioned on that date and time. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You cannot specify a \'startDate\' in a REVOKE_ACCESS request, as startDate is only applicable for GRANT_ACCESS requests to indicate when the access should be provisioned, and it does not make sense in the context of revoking access. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
8023
8023
|
* @summary Submit access request
|
|
8024
8024
|
* @param {AccessRequestV2025} accessRequestV2025
|
|
8025
8025
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -8131,7 +8131,7 @@ var AccessRequestsV2025ApiFp = function (configuration) {
|
|
|
8131
8131
|
* @param {boolean} [count] If this is true, the *X-Total-Count* response header populates with the number of results that would be returned if limit and offset were ignored.
|
|
8132
8132
|
* @param {number} [limit] Max number of results to return.
|
|
8133
8133
|
* @param {number} [offset] Offset into the full result set. Usually specified with *limit* to paginate through the results. Defaults to 0 if not specified.
|
|
8134
|
-
* @param {string} [filters] Filter results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#filtering-results) Filtering is supported for the following fields and operators: **accountActivityItemId**: *eq, in, ge, gt, le, lt, ne, isnull, sw* **accessRequestId**: *in* **status**: *in, eq, ne* **created**: *eq, in, ge, gt, le, lt, ne, isnull, sw*
|
|
8134
|
+
* @param {string} [filters] Filter results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#filtering-results) Filtering is supported for the following fields and operators: **accountActivityItemId**: *eq, in, ge, gt, le, lt, ne, isnull, sw* **accessRequestId**: *in, eq, ne, ge, gt, le, lt, sw* **status**: *in, eq, ne* **created**: *eq, in, ge, gt, le, lt, ne, isnull, sw*
|
|
8135
8135
|
* @param {string} [sorters] Sort results using the standard syntax described in [V3 API Standard Collection Parameters](https://developer.sailpoint.com/idn/api/standard-collection-parameters#sorting-results) Sorting is supported for the following fields: **created, modified, accountActivityItemId, name, accessRequestId**
|
|
8136
8136
|
* @param {string} [requestState] Filter the results by the state of the request. The only valid value is *EXECUTING*.
|
|
8137
8137
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -8252,7 +8252,7 @@ var AccessRequestsV2025ApiFactory = function (configuration, basePath, axios) {
|
|
|
8252
8252
|
return localVarFp.closeAccessRequest(requestParameters.closeAccessRequestV2025, axiosOptions).then(function (request) { return request(axios, basePath); });
|
|
8253
8253
|
},
|
|
8254
8254
|
/**
|
|
8255
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
8255
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `startDate` to set or alter a sunrise date-time on an assignment. The startDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunrise date and its yet to be provisioned, you can also submit a request without a `startDate` to request immediate provisioning after approval. * If a `startDate` is specified, then the requested role, access profile, or entitlement will be provisioned on that date and time. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You cannot specify a \'startDate\' in a REVOKE_ACCESS request, as startDate is only applicable for GRANT_ACCESS requests to indicate when the access should be provisioned, and it does not make sense in the context of revoking access. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
8256
8256
|
* @summary Submit access request
|
|
8257
8257
|
* @param {AccessRequestsV2025ApiCreateAccessRequestRequest} requestParameters Request parameters.
|
|
8258
8258
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -8386,7 +8386,7 @@ var AccessRequestsV2025Api = /** @class */ (function (_super) {
|
|
|
8386
8386
|
return (0, exports.AccessRequestsV2025ApiFp)(this.configuration).closeAccessRequest(requestParameters.closeAccessRequestV2025, axiosOptions).then(function (request) { return request(_this.axios, _this.basePath); });
|
|
8387
8387
|
};
|
|
8388
8388
|
/**
|
|
8389
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
8389
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. >**Security:** idn:access-request:manage is for ORG_ADMIN level. idn:access-request-self:manage is for USER level. :::info The ability to request access using this API is constrained by the Access Request Segments defined in the API token\'s user context. ::: Access requests are processed asynchronously by ISC. A successful response from this endpoint means that the request has been submitted to ISC and is queued for processing. Because this endpoint is asynchronous, it does not return an error if you submit duplicate access requests in quick succession or submit an access request for access that is already in progress, approved, or rejected. It is best practice to check for any existing access requests that reference the same access items before submitting a new access request. This can be accomplished by using the [List Access Request Status](https://developer.sailpoint.com/idn/api/v3/list-access-request-status) or the [Pending Access Request Approvals](https://developer.sailpoint.com/idn/api/v3/list-pending-approvals) APIs. You can also use the [Search API](https://developer.sailpoint.com/idn/api/v3/search) to check the existing access items an identity has before submitting an access request to ensure that you aren\'t requesting access that is already granted. If you use this API to request access that an identity already has, without changing the account details or end date information from the existing assignment, the API will cancel the request as a duplicate. There are two types of access request: __GRANT_ACCESS__ * Can be requested for multiple identities in a single request. * Supports self request and request on behalf of other users. Refer to the [Get Access Request Configuration](https://developer.sailpoint.com/idn/api/v3/get-access-request-config) endpoint for request configuration options. * Allows any authenticated token (except API) to call this endpoint to request to grant access to themselves. Depending on the configuration, a user can request access for others. * Roles, access profiles and entitlements can be requested. * You can specify a `startDate` to set or alter a sunrise date-time on an assignment. The startDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunrise date and its yet to be provisioned, you can also submit a request without a `startDate` to request immediate provisioning after approval. * If a `startDate` is specified, then the requested role, access profile, or entitlement will be provisioned on that date and time. * You can specify a `removeDate` to set or alter a sunset date-time on an assignment. The removeDate must be a future date-time, in the UTC timezone. Additionally, if the user already has the access assigned with a sunset date, you can also submit a request without a `removeDate` to request removal of the sunset date and time. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Now supports an alternate field \'requestedForWithRequestedItems\' for users to specify account selections while requesting items where they have more than one account on the source. :::caution If any entitlements are being requested, then the maximum number of entitlements that can be requested is 25, and the maximum number of identities that can be requested for is 10. If you exceed these limits, the request will fail with a 400 error. If you are not requesting any entitlements, then there are no limits. ::: __REVOKE_ACCESS__ * Can only be requested for a single identity at a time. * You cannot use an access request to revoke access from an identity if that access has been granted by role membership or by birthright provisioning. * Does not support self request. Only manager can request to revoke access for their directly managed employees. * If a `removeDate` is specified, then the requested role, access profile, or entitlement will be removed on that date and time. * Roles, access profiles, and entitlements can be requested for revocation. * Revoke requests for entitlements are limited to 1 entitlement per access request currently. * You cannot specify a \'startDate\' in a REVOKE_ACCESS request, as startDate is only applicable for GRANT_ACCESS requests to indicate when the access should be provisioned, and it does not make sense in the context of revoking access. * You can specify a `removeDate` to add or alter a sunset date and time on an assignment. The `removeDate` must be a future date-time, in the UTC timezone. If the user already has the access assigned with a sunset date and time, the removeDate must be a date-time earlier than the existing sunset date and time. * Allows a manager to request to revoke access for direct employees. A user with ORG_ADMIN authority can also request to revoke access from anyone. * Now supports REVOKE_ACCESS requests for identities with multiple accounts on a single source, with the help of \'assignmentId\' and \'nativeIdentity\' fields. These fields should be used within the \'requestedItems\' section for the revoke requests. * Usage of \'requestedForWithRequestedItems\' field is not supported for revoke requests.
|
|
8390
8390
|
* @summary Submit access request
|
|
8391
8391
|
* @param {AccessRequestsV2025ApiCreateAccessRequestRequest} requestParameters Request parameters.
|
|
8392
8392
|
* @param {*} [axiosOptions] Override http request option.
|