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.
Files changed (49) hide show
  1. package/beta/README.md +2 -2
  2. package/beta/api.ts +71 -11
  3. package/beta/common.ts +2 -2
  4. package/beta/package.json +1 -1
  5. package/dist/beta/api.d.ts +71 -11
  6. package/dist/beta/api.js +8 -8
  7. package/dist/beta/api.js.map +1 -1
  8. package/dist/beta/common.js +2 -2
  9. package/dist/nerm/common.js +2 -2
  10. package/dist/nermv2025/common.js +2 -2
  11. package/dist/v2024/api.d.ts +68 -8
  12. package/dist/v2024/api.js +6 -6
  13. package/dist/v2024/api.js.map +1 -1
  14. package/dist/v2024/common.js +2 -2
  15. package/dist/v2025/api.d.ts +92 -8
  16. package/dist/v2025/api.js +30 -6
  17. package/dist/v2025/api.js.map +1 -1
  18. package/dist/v2025/common.js +2 -2
  19. package/dist/v2026/api.d.ts +475 -184
  20. package/dist/v2026/api.js +744 -441
  21. package/dist/v2026/api.js.map +1 -1
  22. package/dist/v2026/common.js +2 -2
  23. package/dist/v3/api.d.ts +62 -8
  24. package/dist/v3/api.js +6 -6
  25. package/dist/v3/api.js.map +1 -1
  26. package/dist/v3/common.js +2 -2
  27. package/nerm/README.md +2 -2
  28. package/nerm/common.ts +2 -2
  29. package/nerm/package.json +1 -1
  30. package/nermv2025/README.md +2 -2
  31. package/nermv2025/common.ts +2 -2
  32. package/nermv2025/package.json +1 -1
  33. package/package.json +1 -1
  34. package/v2024/README.md +2 -2
  35. package/v2024/api.ts +68 -8
  36. package/v2024/common.ts +2 -2
  37. package/v2024/package.json +1 -1
  38. package/v2025/README.md +2 -2
  39. package/v2025/api.ts +92 -8
  40. package/v2025/common.ts +2 -2
  41. package/v2025/package.json +1 -1
  42. package/v2026/README.md +2 -2
  43. package/v2026/api.ts +822 -370
  44. package/v2026/common.ts +2 -2
  45. package/v2026/package.json +1 -1
  46. package/v3/README.md +2 -2
  47. package/v3/api.ts +62 -8
  48. package/v3/common.ts +2 -2
  49. package/v3/package.json +1 -1
package/beta/README.md CHANGED
@@ -1,4 +1,4 @@
1
- ## sailpoint-sdk@1.8.57
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.57 --save
39
+ npm install sailpoint-sdk@1.8.59 --save
40
40
  ```
41
41
 
42
42
  _unPublished (not recommended):_
package/beta/api.ts CHANGED
@@ -1656,6 +1656,12 @@ export interface AccessRequestAdminItemStatusBeta {
1656
1656
  * @memberof AccessRequestAdminItemStatusBeta
1657
1657
  */
1658
1658
  'description'?: string | null;
1659
+ /**
1660
+ * When the role access is scheduled for provisioning.
1661
+ * @type {string}
1662
+ * @memberof AccessRequestAdminItemStatusBeta
1663
+ */
1664
+ 'startDate'?: string | null;
1659
1665
  /**
1660
1666
  * When the role access is scheduled for removal.
1661
1667
  * @type {string}
@@ -1785,7 +1791,7 @@ export interface AccessRequestBeta {
1785
1791
  */
1786
1792
  'clientMetadata'?: { [key: string]: string; };
1787
1793
  /**
1788
- * 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
1794
+ * 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
1789
1795
  * @type {Array<RequestedForDtoRefBeta>}
1790
1796
  * @memberof AccessRequestBeta
1791
1797
  */
@@ -2001,6 +2007,12 @@ export interface AccessRequestItemBeta {
2001
2007
  * @memberof AccessRequestItemBeta
2002
2008
  */
2003
2009
  'clientMetadata'?: { [key: string]: string; };
2010
+ /**
2011
+ * 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.
2012
+ * @type {string}
2013
+ * @memberof AccessRequestItemBeta
2014
+ */
2015
+ 'startDate'?: string;
2004
2016
  /**
2005
2017
  * 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.
2006
2018
  * @type {string}
@@ -7810,6 +7822,24 @@ export interface CompletedApprovalBeta {
7810
7822
  * @memberof CompletedApprovalBeta
7811
7823
  */
7812
7824
  'currentRemoveDate'?: string | null;
7825
+ /**
7826
+ * The date the role or access profile or entitlement is/will assigned to the specified identity.
7827
+ * @type {string}
7828
+ * @memberof CompletedApprovalBeta
7829
+ */
7830
+ 'startDate'?: string;
7831
+ /**
7832
+ * If true, then the request is to change the start date or sunrise date.
7833
+ * @type {boolean}
7834
+ * @memberof CompletedApprovalBeta
7835
+ */
7836
+ 'startUpdateRequested'?: boolean;
7837
+ /**
7838
+ * The start date or sunrise date that was assigned at the time of the request.
7839
+ * @type {string}
7840
+ * @memberof CompletedApprovalBeta
7841
+ */
7842
+ 'currentStartDate'?: string;
7813
7843
  /**
7814
7844
  *
7815
7845
  * @type {SodViolationContextCheckCompleted2Beta}
@@ -21634,6 +21664,24 @@ export interface PendingApprovalBeta {
21634
21664
  * @memberof PendingApprovalBeta
21635
21665
  */
21636
21666
  'currentRemoveDate'?: string;
21667
+ /**
21668
+ * The date the role or access profile or entitlement is/will assigned to the specified identity.
21669
+ * @type {string}
21670
+ * @memberof PendingApprovalBeta
21671
+ */
21672
+ 'startDate'?: string;
21673
+ /**
21674
+ * If true, then the request is to change the start date or sunrise date.
21675
+ * @type {boolean}
21676
+ * @memberof PendingApprovalBeta
21677
+ */
21678
+ 'startUpdateRequested'?: boolean;
21679
+ /**
21680
+ * The start date or sunrise date that was assigned at the time of the request.
21681
+ * @type {string}
21682
+ * @memberof PendingApprovalBeta
21683
+ */
21684
+ 'currentStartDate'?: string;
21637
21685
  /**
21638
21686
  *
21639
21687
  * @type {SodViolationContextCheckCompleted2Beta}
@@ -23582,6 +23630,12 @@ export interface RequestedItemDtoRefBeta {
23582
23630
  * @memberof RequestedItemDtoRefBeta
23583
23631
  */
23584
23632
  'clientMetadata'?: { [key: string]: string; };
23633
+ /**
23634
+ * 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.
23635
+ * @type {string}
23636
+ * @memberof RequestedItemDtoRefBeta
23637
+ */
23638
+ 'startDate'?: string;
23585
23639
  /**
23586
23640
  * 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.
23587
23641
  * @type {string}
@@ -23736,6 +23790,12 @@ export interface RequestedItemStatusBeta {
23736
23790
  * @memberof RequestedItemStatusBeta
23737
23791
  */
23738
23792
  'description'?: string | null;
23793
+ /**
23794
+ * When the role access is scheduled for provisioning.
23795
+ * @type {string}
23796
+ * @memberof RequestedItemStatusBeta
23797
+ */
23798
+ 'startDate'?: string | null;
23739
23799
  /**
23740
23800
  * When the role access is scheduled for removal.
23741
23801
  * @type {string}
@@ -37961,7 +38021,7 @@ export const AccessRequestsBetaApiAxiosParamCreator = function (configuration?:
37961
38021
  };
37962
38022
  },
37963
38023
  /**
37964
- * 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.
38024
+ * 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.
37965
38025
  * @summary Submit access request
37966
38026
  * @param {AccessRequestBeta} accessRequestBeta
37967
38027
  * @param {*} [axiosOptions] Override http request option.
@@ -38053,7 +38113,7 @@ export const AccessRequestsBetaApiAxiosParamCreator = function (configuration?:
38053
38113
  * @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.
38054
38114
  * @param {number} [limit] Max number of results to return.
38055
38115
  * @param {number} [offset] Offset into the full result set. Usually specified with *limit* to paginate through the results. Defaults to 0 if not specified.
38056
- * @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: **accessRequestId**: *eq, ge, gt, le, lt, ne, sw* **accountActivityItemId**: *eq, in, ge, gt, le, ne, sw* **created**: *eq, ge, gt, le, lt, ne*
38116
+ * @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: **accessRequestId**: *eq, ge, gt, le, lt, ne, in, sw* **accountActivityItemId**: *eq, in, ge, gt, le, ne, sw* **created**: *eq, ge, gt, le, lt, ne*
38057
38117
  * @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**
38058
38118
  * @param {string} [requestState] Filter the results by the state of the request. The only valid value is *EXECUTING*.
38059
38119
  * @param {*} [axiosOptions] Override http request option.
@@ -38142,7 +38202,7 @@ export const AccessRequestsBetaApiAxiosParamCreator = function (configuration?:
38142
38202
  * @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.
38143
38203
  * @param {number} [limit] Max number of results to return.
38144
38204
  * @param {number} [offset] Offset into the full result set. Usually specified with *limit* to paginate through the results. Defaults to 0 if not specified.
38145
- * @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*
38205
+ * @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*
38146
38206
  * @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**
38147
38207
  * @param {string} [requestState] Filter the results by the state of the request. The only valid value is *EXECUTING*.
38148
38208
  * @param {*} [axiosOptions] Override http request option.
@@ -38311,7 +38371,7 @@ export const AccessRequestsBetaApiFp = function(configuration?: Configuration) {
38311
38371
  return (axios, basePath) => createRequestFunction(localVarAxiosArgs, globalAxios, BASE_PATH, configuration)(axios, localVarOperationServerBasePath || basePath);
38312
38372
  },
38313
38373
  /**
38314
- * 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.
38374
+ * 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.
38315
38375
  * @summary Submit access request
38316
38376
  * @param {AccessRequestBeta} accessRequestBeta
38317
38377
  * @param {*} [axiosOptions] Override http request option.
@@ -38346,7 +38406,7 @@ export const AccessRequestsBetaApiFp = function(configuration?: Configuration) {
38346
38406
  * @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.
38347
38407
  * @param {number} [limit] Max number of results to return.
38348
38408
  * @param {number} [offset] Offset into the full result set. Usually specified with *limit* to paginate through the results. Defaults to 0 if not specified.
38349
- * @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: **accessRequestId**: *eq, ge, gt, le, lt, ne, sw* **accountActivityItemId**: *eq, in, ge, gt, le, ne, sw* **created**: *eq, ge, gt, le, lt, ne*
38409
+ * @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: **accessRequestId**: *eq, ge, gt, le, lt, ne, in, sw* **accountActivityItemId**: *eq, in, ge, gt, le, ne, sw* **created**: *eq, ge, gt, le, lt, ne*
38350
38410
  * @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**
38351
38411
  * @param {string} [requestState] Filter the results by the state of the request. The only valid value is *EXECUTING*.
38352
38412
  * @param {*} [axiosOptions] Override http request option.
@@ -38369,7 +38429,7 @@ export const AccessRequestsBetaApiFp = function(configuration?: Configuration) {
38369
38429
  * @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.
38370
38430
  * @param {number} [limit] Max number of results to return.
38371
38431
  * @param {number} [offset] Offset into the full result set. Usually specified with *limit* to paginate through the results. Defaults to 0 if not specified.
38372
- * @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*
38432
+ * @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*
38373
38433
  * @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**
38374
38434
  * @param {string} [requestState] Filter the results by the state of the request. The only valid value is *EXECUTING*.
38375
38435
  * @param {*} [axiosOptions] Override http request option.
@@ -38426,7 +38486,7 @@ export const AccessRequestsBetaApiFactory = function (configuration?: Configurat
38426
38486
  return localVarFp.closeAccessRequest(requestParameters.closeAccessRequestBeta, axiosOptions).then((request) => request(axios, basePath));
38427
38487
  },
38428
38488
  /**
38429
- * 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.
38489
+ * 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.
38430
38490
  * @summary Submit access request
38431
38491
  * @param {AccessRequestsBetaApiCreateAccessRequestRequest} requestParameters Request parameters.
38432
38492
  * @param {*} [axiosOptions] Override http request option.
@@ -38577,7 +38637,7 @@ export interface AccessRequestsBetaApiListAccessRequestStatusRequest {
38577
38637
  readonly offset?: number
38578
38638
 
38579
38639
  /**
38580
- * 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: **accessRequestId**: *eq, ge, gt, le, lt, ne, sw* **accountActivityItemId**: *eq, in, ge, gt, le, ne, sw* **created**: *eq, ge, gt, le, lt, ne*
38640
+ * 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: **accessRequestId**: *eq, ge, gt, le, lt, ne, in, sw* **accountActivityItemId**: *eq, in, ge, gt, le, ne, sw* **created**: *eq, ge, gt, le, lt, ne*
38581
38641
  * @type {string}
38582
38642
  * @memberof AccessRequestsBetaApiListAccessRequestStatus
38583
38643
  */
@@ -38661,7 +38721,7 @@ export interface AccessRequestsBetaApiListAdministratorsAccessRequestStatusReque
38661
38721
  readonly offset?: number
38662
38722
 
38663
38723
  /**
38664
- * 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*
38724
+ * 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*
38665
38725
  * @type {string}
38666
38726
  * @memberof AccessRequestsBetaApiListAdministratorsAccessRequestStatus
38667
38727
  */
@@ -38728,7 +38788,7 @@ export class AccessRequestsBetaApi extends BaseAPI {
38728
38788
  }
38729
38789
 
38730
38790
  /**
38731
- * 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.
38791
+ * 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.
38732
38792
  * @summary Submit access request
38733
38793
  * @param {AccessRequestsBetaApiCreateAccessRequestRequest} requestParameters Request parameters.
38734
38794
  * @param {*} [axiosOptions] Override http request option.
package/beta/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.57`;
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.57'},
156
+ ...{'X-SailPoint-SDK':'typescript-1.8.59'},
157
157
  ...{'User-Agent': userAgent},
158
158
  }
159
159
 
package/beta/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "sailpoint-sdk",
3
- "version": "1.8.57",
3
+ "version": "1.8.59",
4
4
  "description": "OpenAPI client for sailpoint-sdk",
5
5
  "author": "OpenAPI-Generator Contributors",
6
6
  "repository": {