sailpoint-api-client 1.8.57 → 1.8.59
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 +71 -11
- package/beta/common.ts +2 -2
- package/beta/package.json +1 -1
- package/dist/beta/api.d.ts +71 -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 +68 -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 +92 -8
- package/dist/v2025/api.js +30 -6
- package/dist/v2025/api.js.map +1 -1
- package/dist/v2025/common.js +2 -2
- package/dist/v2026/api.d.ts +475 -184
- package/dist/v2026/api.js +744 -441
- package/dist/v2026/api.js.map +1 -1
- package/dist/v2026/common.js +2 -2
- package/dist/v3/api.d.ts +62 -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 +68 -8
- package/v2024/common.ts +2 -2
- package/v2024/package.json +1 -1
- package/v2025/README.md +2 -2
- package/v2025/api.ts +92 -8
- package/v2025/common.ts +2 -2
- package/v2025/package.json +1 -1
- package/v2026/README.md +2 -2
- package/v2026/api.ts +822 -370
- package/v2026/common.ts +2 -2
- package/v2026/package.json +1 -1
- package/v3/README.md +2 -2
- package/v3/api.ts +62 -8
- package/v3/common.ts +2 -2
- package/v3/package.json +1 -1
package/dist/v3/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.59";
|
|
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.59' }), { '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/nerm/README.md
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
## sailpoint-nerm-sdk@1.8.
|
|
1
|
+
## sailpoint-nerm-sdk@1.8.59
|
|
2
2
|
|
|
3
3
|
This generator creates TypeScript/JavaScript client that utilizes [axios](https://github.com/axios/axios). The generated Node module can be used in the following environments:
|
|
4
4
|
|
|
@@ -36,7 +36,7 @@ navigate to the folder of your consuming project and run one of the following co
|
|
|
36
36
|
_published:_
|
|
37
37
|
|
|
38
38
|
```
|
|
39
|
-
npm install sailpoint-nerm-sdk@1.8.
|
|
39
|
+
npm install sailpoint-nerm-sdk@1.8.59 --save
|
|
40
40
|
```
|
|
41
41
|
|
|
42
42
|
_unPublished (not recommended):_
|
package/nerm/common.ts
CHANGED
|
@@ -146,7 +146,7 @@ export const toPathString = function (url: URL) {
|
|
|
146
146
|
export const createRequestFunction = function (axiosArgs: RequestArgs, globalAxios: AxiosInstance, BASE_PATH: string, configuration?: Configuration) {
|
|
147
147
|
return <T = unknown, R = AxiosResponse<T>>(axios: AxiosInstance = globalAxios, basePath: string = BASE_PATH) => {
|
|
148
148
|
axiosRetry(axios, configuration.retriesConfig)
|
|
149
|
-
let userAgent = `SailPoint-SDK-TypeScript/1.8.
|
|
149
|
+
let userAgent = `SailPoint-SDK-TypeScript/1.8.59`;
|
|
150
150
|
if (configuration?.consumerIdentifier && configuration?.consumerVersion) {
|
|
151
151
|
userAgent += ` (${configuration.consumerIdentifier}/${configuration.consumerVersion})`;
|
|
152
152
|
}
|
|
@@ -154,7 +154,7 @@ export const createRequestFunction = function (axiosArgs: RequestArgs, globalAxi
|
|
|
154
154
|
const headers = {
|
|
155
155
|
...{'Accept': 'application/json'},
|
|
156
156
|
...axiosArgs.axiosOptions.headers,
|
|
157
|
-
...{'X-SailPoint-SDK':'typescript-1.8.
|
|
157
|
+
...{'X-SailPoint-SDK':'typescript-1.8.59'},
|
|
158
158
|
...{'User-Agent': userAgent},
|
|
159
159
|
}
|
|
160
160
|
|
package/nerm/package.json
CHANGED
package/nermv2025/README.md
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
## sailpoint-nerm-sdk@1.8.
|
|
1
|
+
## sailpoint-nerm-sdk@1.8.59
|
|
2
2
|
|
|
3
3
|
This generator creates TypeScript/JavaScript client that utilizes [axios](https://github.com/axios/axios). The generated Node module can be used in the following environments:
|
|
4
4
|
|
|
@@ -36,7 +36,7 @@ navigate to the folder of your consuming project and run one of the following co
|
|
|
36
36
|
_published:_
|
|
37
37
|
|
|
38
38
|
```
|
|
39
|
-
npm install sailpoint-nerm-sdk@1.8.
|
|
39
|
+
npm install sailpoint-nerm-sdk@1.8.59 --save
|
|
40
40
|
```
|
|
41
41
|
|
|
42
42
|
_unPublished (not recommended):_
|
package/nermv2025/common.ts
CHANGED
|
@@ -146,7 +146,7 @@ export const toPathString = function (url: URL) {
|
|
|
146
146
|
export const createRequestFunction = function (axiosArgs: RequestArgs, globalAxios: AxiosInstance, BASE_PATH: string, configuration?: Configuration) {
|
|
147
147
|
return <T = unknown, R = AxiosResponse<T>>(axios: AxiosInstance = globalAxios, basePath: string = BASE_PATH) => {
|
|
148
148
|
axiosRetry(axios, configuration.retriesConfig)
|
|
149
|
-
let userAgent = `SailPoint-SDK-TypeScript/1.8.
|
|
149
|
+
let userAgent = `SailPoint-SDK-TypeScript/1.8.59`;
|
|
150
150
|
if (configuration?.consumerIdentifier && configuration?.consumerVersion) {
|
|
151
151
|
userAgent += ` (${configuration.consumerIdentifier}/${configuration.consumerVersion})`;
|
|
152
152
|
}
|
|
@@ -154,7 +154,7 @@ export const createRequestFunction = function (axiosArgs: RequestArgs, globalAxi
|
|
|
154
154
|
const headers = {
|
|
155
155
|
...{'Accept': 'application/json'},
|
|
156
156
|
...axiosArgs.axiosOptions.headers,
|
|
157
|
-
...{'X-SailPoint-SDK':'typescript-1.8.
|
|
157
|
+
...{'X-SailPoint-SDK':'typescript-1.8.59'},
|
|
158
158
|
...{'User-Agent': userAgent},
|
|
159
159
|
}
|
|
160
160
|
|
package/nermv2025/package.json
CHANGED
package/package.json
CHANGED
package/v2024/README.md
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
## sailpoint-sdk@1.8.
|
|
1
|
+
## sailpoint-sdk@1.8.59
|
|
2
2
|
|
|
3
3
|
This generator creates TypeScript/JavaScript client that utilizes [axios](https://github.com/axios/axios). The generated Node module can be used in the following environments:
|
|
4
4
|
|
|
@@ -36,7 +36,7 @@ navigate to the folder of your consuming project and run one of the following co
|
|
|
36
36
|
_published:_
|
|
37
37
|
|
|
38
38
|
```
|
|
39
|
-
npm install sailpoint-sdk@1.8.
|
|
39
|
+
npm install sailpoint-sdk@1.8.59 --save
|
|
40
40
|
```
|
|
41
41
|
|
|
42
42
|
_unPublished (not recommended):_
|
package/v2024/api.ts
CHANGED
|
@@ -2187,6 +2187,12 @@ export interface AccessRequestAdminItemStatusV2024 {
|
|
|
2187
2187
|
* @memberof AccessRequestAdminItemStatusV2024
|
|
2188
2188
|
*/
|
|
2189
2189
|
'description'?: string | null;
|
|
2190
|
+
/**
|
|
2191
|
+
* When the role access is scheduled for provisioning.
|
|
2192
|
+
* @type {string}
|
|
2193
|
+
* @memberof AccessRequestAdminItemStatusV2024
|
|
2194
|
+
*/
|
|
2195
|
+
'startDate'?: string | null;
|
|
2190
2196
|
/**
|
|
2191
2197
|
* When the role access is scheduled for removal.
|
|
2192
2198
|
* @type {string}
|
|
@@ -2472,6 +2478,12 @@ export interface AccessRequestItemV2024 {
|
|
|
2472
2478
|
* @memberof AccessRequestItemV2024
|
|
2473
2479
|
*/
|
|
2474
2480
|
'clientMetadata'?: { [key: string]: string; };
|
|
2481
|
+
/**
|
|
2482
|
+
* 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.
|
|
2483
|
+
* @type {string}
|
|
2484
|
+
* @memberof AccessRequestItemV2024
|
|
2485
|
+
*/
|
|
2486
|
+
'startDate'?: string;
|
|
2475
2487
|
/**
|
|
2476
2488
|
* 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.
|
|
2477
2489
|
* @type {string}
|
|
@@ -3146,7 +3158,7 @@ export interface AccessRequestV2024 {
|
|
|
3146
3158
|
*/
|
|
3147
3159
|
'clientMetadata'?: { [key: string]: string; };
|
|
3148
3160
|
/**
|
|
3149
|
-
* 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
|
|
3161
|
+
* 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
|
|
3150
3162
|
* @type {Array<RequestedForDtoRefV2024>}
|
|
3151
3163
|
* @memberof AccessRequestV2024
|
|
3152
3164
|
*/
|
|
@@ -11354,6 +11366,24 @@ export interface CompletedApprovalV2024 {
|
|
|
11354
11366
|
* @memberof CompletedApprovalV2024
|
|
11355
11367
|
*/
|
|
11356
11368
|
'currentRemoveDate'?: string | null;
|
|
11369
|
+
/**
|
|
11370
|
+
* The date the role or access profile or entitlement is/will assigned to the specified identity.
|
|
11371
|
+
* @type {string}
|
|
11372
|
+
* @memberof CompletedApprovalV2024
|
|
11373
|
+
*/
|
|
11374
|
+
'startDate'?: string;
|
|
11375
|
+
/**
|
|
11376
|
+
* If true, then the request is to change the start date or sunrise date.
|
|
11377
|
+
* @type {boolean}
|
|
11378
|
+
* @memberof CompletedApprovalV2024
|
|
11379
|
+
*/
|
|
11380
|
+
'startUpdateRequested'?: boolean;
|
|
11381
|
+
/**
|
|
11382
|
+
* The start date or sunrise date that was assigned at the time of the request.
|
|
11383
|
+
* @type {string}
|
|
11384
|
+
* @memberof CompletedApprovalV2024
|
|
11385
|
+
*/
|
|
11386
|
+
'currentStartDate'?: string;
|
|
11357
11387
|
/**
|
|
11358
11388
|
*
|
|
11359
11389
|
* @type {SodViolationContextCheckCompletedV2024}
|
|
@@ -29063,6 +29093,24 @@ export interface PendingApprovalV2024 {
|
|
|
29063
29093
|
* @memberof PendingApprovalV2024
|
|
29064
29094
|
*/
|
|
29065
29095
|
'currentRemoveDate'?: string;
|
|
29096
|
+
/**
|
|
29097
|
+
* The date the role or access profile or entitlement is/will assigned to the specified identity.
|
|
29098
|
+
* @type {string}
|
|
29099
|
+
* @memberof PendingApprovalV2024
|
|
29100
|
+
*/
|
|
29101
|
+
'startDate'?: string;
|
|
29102
|
+
/**
|
|
29103
|
+
* If true, then the request is to change the start date or sunrise date.
|
|
29104
|
+
* @type {boolean}
|
|
29105
|
+
* @memberof PendingApprovalV2024
|
|
29106
|
+
*/
|
|
29107
|
+
'startUpdateRequested'?: boolean;
|
|
29108
|
+
/**
|
|
29109
|
+
* The start date or sunrise date that was assigned at the time of the request.
|
|
29110
|
+
* @type {string}
|
|
29111
|
+
* @memberof PendingApprovalV2024
|
|
29112
|
+
*/
|
|
29113
|
+
'currentStartDate'?: string;
|
|
29066
29114
|
/**
|
|
29067
29115
|
*
|
|
29068
29116
|
* @type {SodViolationContextCheckCompletedV2024}
|
|
@@ -31531,6 +31579,12 @@ export interface RequestedItemDtoRefV2024 {
|
|
|
31531
31579
|
* @memberof RequestedItemDtoRefV2024
|
|
31532
31580
|
*/
|
|
31533
31581
|
'clientMetadata'?: { [key: string]: string; };
|
|
31582
|
+
/**
|
|
31583
|
+
* 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.
|
|
31584
|
+
* @type {string}
|
|
31585
|
+
* @memberof RequestedItemDtoRefV2024
|
|
31586
|
+
*/
|
|
31587
|
+
'startDate'?: string;
|
|
31534
31588
|
/**
|
|
31535
31589
|
* 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.
|
|
31536
31590
|
* @type {string}
|
|
@@ -31867,6 +31921,12 @@ export interface RequestedItemStatusV2024 {
|
|
|
31867
31921
|
* @memberof RequestedItemStatusV2024
|
|
31868
31922
|
*/
|
|
31869
31923
|
'description'?: string | null;
|
|
31924
|
+
/**
|
|
31925
|
+
* When the role access is scheduled for provisioning.
|
|
31926
|
+
* @type {string}
|
|
31927
|
+
* @memberof RequestedItemStatusV2024
|
|
31928
|
+
*/
|
|
31929
|
+
'startDate'?: string | null;
|
|
31870
31930
|
/**
|
|
31871
31931
|
* When the role access is scheduled for removal.
|
|
31872
31932
|
* @type {string}
|
|
@@ -49254,7 +49314,7 @@ export const AccessRequestsV2024ApiAxiosParamCreator = function (configuration?:
|
|
|
49254
49314
|
};
|
|
49255
49315
|
},
|
|
49256
49316
|
/**
|
|
49257
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. :::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.
|
|
49317
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. :::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.
|
|
49258
49318
|
* @summary Submit access request
|
|
49259
49319
|
* @param {AccessRequestV2024} accessRequestV2024
|
|
49260
49320
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -49489,7 +49549,7 @@ export const AccessRequestsV2024ApiAxiosParamCreator = function (configuration?:
|
|
|
49489
49549
|
* @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.
|
|
49490
49550
|
* @param {number} [limit] Max number of results to return.
|
|
49491
49551
|
* @param {number} [offset] Offset into the full result set. Usually specified with *limit* to paginate through the results. Defaults to 0 if not specified.
|
|
49492
|
-
* @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*
|
|
49552
|
+
* @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*
|
|
49493
49553
|
* @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**
|
|
49494
49554
|
* @param {string} [requestState] Filter the results by the state of the request. The only valid value is *EXECUTING*.
|
|
49495
49555
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -49736,7 +49796,7 @@ export const AccessRequestsV2024ApiFp = function(configuration?: Configuration)
|
|
|
49736
49796
|
return (axios, basePath) => createRequestFunction(localVarAxiosArgs, globalAxios, BASE_PATH, configuration)(axios, localVarOperationServerBasePath || basePath);
|
|
49737
49797
|
},
|
|
49738
49798
|
/**
|
|
49739
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. :::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.
|
|
49799
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. :::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.
|
|
49740
49800
|
* @summary Submit access request
|
|
49741
49801
|
* @param {AccessRequestV2024} accessRequestV2024
|
|
49742
49802
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -49809,7 +49869,7 @@ export const AccessRequestsV2024ApiFp = function(configuration?: Configuration)
|
|
|
49809
49869
|
* @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.
|
|
49810
49870
|
* @param {number} [limit] Max number of results to return.
|
|
49811
49871
|
* @param {number} [offset] Offset into the full result set. Usually specified with *limit* to paginate through the results. Defaults to 0 if not specified.
|
|
49812
|
-
* @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*
|
|
49872
|
+
* @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*
|
|
49813
49873
|
* @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**
|
|
49814
49874
|
* @param {string} [requestState] Filter the results by the state of the request. The only valid value is *EXECUTING*.
|
|
49815
49875
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -49900,7 +49960,7 @@ export const AccessRequestsV2024ApiFactory = function (configuration?: Configura
|
|
|
49900
49960
|
return localVarFp.closeAccessRequest(requestParameters.closeAccessRequestV2024, axiosOptions).then((request) => request(axios, basePath));
|
|
49901
49961
|
},
|
|
49902
49962
|
/**
|
|
49903
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. :::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.
|
|
49963
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. :::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.
|
|
49904
49964
|
* @summary Submit access request
|
|
49905
49965
|
* @param {AccessRequestsV2024ApiCreateAccessRequestRequest} requestParameters Request parameters.
|
|
49906
49966
|
* @param {*} [axiosOptions] Override http request option.
|
|
@@ -50211,7 +50271,7 @@ export interface AccessRequestsV2024ApiListAdministratorsAccessRequestStatusRequ
|
|
|
50211
50271
|
readonly offset?: number
|
|
50212
50272
|
|
|
50213
50273
|
/**
|
|
50214
|
-
* 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*
|
|
50274
|
+
* 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*
|
|
50215
50275
|
* @type {string}
|
|
50216
50276
|
* @memberof AccessRequestsV2024ApiListAdministratorsAccessRequestStatus
|
|
50217
50277
|
*/
|
|
@@ -50323,7 +50383,7 @@ export class AccessRequestsV2024Api extends BaseAPI {
|
|
|
50323
50383
|
}
|
|
50324
50384
|
|
|
50325
50385
|
/**
|
|
50326
|
-
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. :::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.
|
|
50386
|
+
* Use this API to submit an access request in Identity Security Cloud (ISC), where it follows any ISC approval processes. :::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.
|
|
50327
50387
|
* @summary Submit access request
|
|
50328
50388
|
* @param {AccessRequestsV2024ApiCreateAccessRequestRequest} requestParameters Request parameters.
|
|
50329
50389
|
* @param {*} [axiosOptions] Override http request option.
|
package/v2024/common.ts
CHANGED
|
@@ -146,14 +146,14 @@ export const toPathString = function (url: URL) {
|
|
|
146
146
|
export const createRequestFunction = function (axiosArgs: RequestArgs, globalAxios: AxiosInstance, BASE_PATH: string, configuration?: Configuration) {
|
|
147
147
|
return <T = unknown, R = AxiosResponse<T>>(axios: AxiosInstance = globalAxios, basePath: string = BASE_PATH) => {
|
|
148
148
|
axiosRetry(axios, configuration.retriesConfig)
|
|
149
|
-
let userAgent = `SailPoint-SDK-TypeScript/1.8.
|
|
149
|
+
let userAgent = `SailPoint-SDK-TypeScript/1.8.59`;
|
|
150
150
|
if (configuration?.consumerIdentifier && configuration?.consumerVersion) {
|
|
151
151
|
userAgent += ` (${configuration.consumerIdentifier}/${configuration.consumerVersion})`;
|
|
152
152
|
}
|
|
153
153
|
userAgent += ` (${process.platform}; ${process.arch}) Node/${process.versions.node} (openapi-generator/7.12.0)`;
|
|
154
154
|
const headers = {
|
|
155
155
|
...axiosArgs.axiosOptions.headers,
|
|
156
|
-
...{'X-SailPoint-SDK':'typescript-1.8.
|
|
156
|
+
...{'X-SailPoint-SDK':'typescript-1.8.59'},
|
|
157
157
|
...{'User-Agent': userAgent},
|
|
158
158
|
}
|
|
159
159
|
|
package/v2024/package.json
CHANGED
package/v2025/README.md
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
## sailpoint-sdk@1.8.
|
|
1
|
+
## sailpoint-sdk@1.8.59
|
|
2
2
|
|
|
3
3
|
This generator creates TypeScript/JavaScript client that utilizes [axios](https://github.com/axios/axios). The generated Node module can be used in the following environments:
|
|
4
4
|
|
|
@@ -36,7 +36,7 @@ navigate to the folder of your consuming project and run one of the following co
|
|
|
36
36
|
_published:_
|
|
37
37
|
|
|
38
38
|
```
|
|
39
|
-
npm install sailpoint-sdk@1.8.
|
|
39
|
+
npm install sailpoint-sdk@1.8.59 --save
|
|
40
40
|
```
|
|
41
41
|
|
|
42
42
|
_unPublished (not recommended):_
|