LukeParke/api-specs
1
0
Fork 0
mirror of https://github.com/LukeHagar/api-specs.git synced 2025-12-06 12:27:48 +00:00
Code Issues Packages Projects Releases Wiki Activity

Apply automatic changes

Browse Source
This commit is contained in:
tyler-mairose-sp
2024-03-25 13:12:28 +00:00
committed by github-actions[bot]
parent aa3530bba3
commit 201e9c57e9
7 changed files with 10023 additions and 7523 deletions
Download Patch File Download Diff File Expand all files Collapse all files

961
dereferenced/deref-sailpoint-api.beta.json
View File

@@ -210,7 +210,7 @@
},
{
"name": "Segments",
"description": "Use this API to implement and customize access request segment functionality. \nWith this functionality in place, administrators can create and manage access request segments. \nSegments provide organizations with a way to make the access their users have even more granular - this can simply the access request process for the organization's users and improves security by reducing the risk of overprovisoning access. \n\nSegments represent sets of identities, all grouped by specified identity attributes, who are only able to see and access the access items associated with their segments.\nFor example, administrators could group all their organization's London office employees into one segment, \"London Office Employees,\" by their shared location. \nThe administrators could then define the access items the London employees would need, and the identities in the \"London Office Employees\" would then only be able to see and access those items.\n\nIn IdentityNow, administrators can use the 'Access' drop-down menu and select 'Segments' to reach the 'Access Requests Segments' page. \nThis page lists all the existing access request segments, along with their statuses, enabled or disabled. \nAdministrators can use this page to create, edit, enable, disable, and delete segments. \nTo create a segment, an administrator must provide a name, define the identities grouped in the segment, and define the items the identities in the segment can access.\nThese items can be access profiles, roles, or entitlements. \n\nWhen administrators use the API to create and manage segments, they use a JSON expression in the `visibilityCriteria` object to define the segment's identities and access items. \n\nRefer to [Managing Access Request Segments](https://documentation.sailpoint.com/saas/help/requests/segments.html) for more information about segments in IdentityNow. \n"
"description": "Use this API to implement and customize access request segment functionality. \nWith this functionality in place, administrators can create and manage access request segments. \nSegments provide organizations with a way to make the access their users have even more granular - this can simply the access request process for the organization's users and improves security by reducing the risk of overprovisoning access. \n\nSegments represent sets of identities, all grouped by specified identity attributes, who are only able to see and access the access items associated with their segments.\nFor example, administrators could group all their organization's London office employees into one segment, \"London Office Employees,\" by their shared location. \nThe administrators could then define the access items the London employees would need, and the identities in the \"London Office Employees\" would then only be able to see and access those items.\n\nIn IdentityNow, administrators can use the 'Access' drop-down menu and select 'Segments' to reach the 'Access Requests Segments' page. \nThis page lists all the existing access request segments, along with their statuses, enabled or disabled. \nAdministrators can use this page to create, edit, enable, disable, and delete segments. \nTo create a segment, an administrator must provide a name, define the identities grouped in the segment, and define the items the identities in the segment can access.\nThese items can be access profiles, roles, or entitlements. \n\nWhen administrators use the API to create and manage segments, they use a JSON expression in the `visibilityCriteria` object to define the segment's identities and access items. \n\nRefer to [Managing Access Request Segments](https://documentation.sailpoint.com/saas/help/requests/segments.html) for more information about segments in IdentityNow.\n"
},
{
"name": "Service Desk Integration",
@@ -218,11 +218,11 @@
},
{
"name": "SOD Policy",
"description": "Use this API to implement and manage \"separation of duties\" (SOD) policies. \nWith SOD policy functionality in place, administrators can organize the access in their tenants to prevent individuals from gaining conflicting or excessive access. \n\n\"Separation of duties\" refers to the concept that people shouldn't have conflicting sets of access - all their access should be configured in a way that protects your organization's assets and data. \nFor example, people who record monetary transactions shouldn't be able to issue payment for those transactions.\nAny changes to major system configurations should be approved by someone other than the person requesting the change. \n\nOrganizations can use \"separation of duties\" (SOD) policies to enforce and track their internal security rules throughout their tenants.\nThese SOD policies limit each user's involvement in important processes and protects the organization from individuals gaining excessive access. \n\nTo create SOD policies in IdentityNow, administrators use 'Search' and then access 'Policies'.\nTo create a policy, they must configure two lists of access items. Each access item can only be added to one of the two lists.\nThey can search for the entitlements they want to add to these access lists.\n\n>Note: You can have a maximum of 500 policies of any type (including general policies) in your organization. In each access-based SOD policy, you can have a maximum of 50 entitlements in each access list.\n\nOnce a SOD policy is in place, if an identity has access items on both lists, a SOD violation will trigger. \nThese violations are included in SOD violation reports that other users will see in emails at regular intervals if they're subscribed to the SOD policy.\nThe other users can then better help to enforce these SOD policies. \n\nTo create a subscription to a SOD policy in IdentityNow, administrators use 'Search' and then access 'Layers'.\nThey can create a subscription to the policy and schedule it to run at a regular interval. \n\nRefer to [Managing Policies](https://documentation.sailpoint.com/saas/help/sod/manage-policies.html) for more information about SOD policies. \n\nRefer to [Subscribe to a SOD Policy](https://documentation.sailpoint.com/saas/help/sod/policy-violations.html#subscribe-to-an-sod-policy) for more information about SOD policy subscriptions. \n"
"description": "Use this API to implement and manage \"separation of duties\" (SOD) policies. \nWith SOD policy functionality in place, administrators can organize the access in their tenants to prevent individuals from gaining conflicting or excessive access. \n\n\"Separation of duties\" refers to the concept that people shouldn't have conflicting sets of access - all their access should be configured in a way that protects your organization's assets and data. \nFor example, people who record monetary transactions shouldn't be able to issue payment for those transactions.\nAny changes to major system configurations should be approved by someone other than the person requesting the change. \n\nOrganizations can use \"separation of duties\" (SOD) policies to enforce and track their internal security rules throughout their tenants.\nThese SOD policies limit each user's involvement in important processes and protects the organization from individuals gaining excessive access. \n\nTo create SOD policies in IdentityNow, administrators use 'Search' and then access 'Policies'.\nTo create a policy, they must configure two lists of access items. Each access item can only be added to one of the two lists.\nThey can search for the entitlements they want to add to these access lists.\n\n>Note: You can have a maximum of 500 policies of any type (including general policies) in your organization. In each access-based SOD policy, you can have a maximum of 50 entitlements in each access list.\n\nOnce a SOD policy is in place, if an identity has access items on both lists, a SOD violation will trigger. \nThese violations are included in SOD violation reports that other users will see in emails at regular intervals if they're subscribed to the SOD policy.\nThe other users can then better help to enforce these SOD policies. \n\nTo create a subscription to a SOD policy in IdentityNow, administrators use 'Search' and then access 'Layers'.\nThey can create a subscription to the policy and schedule it to run at a regular interval. \n\nRefer to [Managing Policies](https://documentation.sailpoint.com/saas/help/sod/manage-policies.html) for more information about SOD policies. \n\nRefer to [Subscribe to a SOD Policy](https://documentation.sailpoint.com/saas/help/sod/policy-violations.html#subscribe-to-an-sod-policy) for more information about SOD policy subscriptions.\n"
},
{
"name": "SOD Violations",
"description": "Use this API to check for current \"separation of duties\" (SOD) policy violations as well as potential future SOD policy violations. \nWith SOD violation functionality in place, administrators can get information about current SOD policy violations and predict whether an access change will trigger new violations, which helps to prevent them from occurring at all. \n\n\"Separation of duties\" refers to the concept that people shouldn't have conflicting sets of access - all their access should be configured in a way that protects your organization's assets and data. \nFor example, people who record monetary transactions shouldn't be able to issue payment for those transactions.\nAny changes to major system configurations should be approved by someone other than the person requesting the change. \n\nOrganizations can use \"separation of duties\" (SOD) policies to enforce and track their internal security rules throughout their tenants.\nThese SOD policies limit each user's involvement in important processes and protects the organization from individuals gaining excessive access. \n\nOnce a SOD policy is in place, if an identity has conflicting access items, a SOD violation will trigger. \nThese violations are included in SOD violation reports that other users will see in emails at regular intervals if they're subscribed to the SOD policy.\nThe other users can then better help to enforce these SOD policies.\n\nAdministrators can use the SOD violations APIs to check a set of identities for any current SOD violations, and they can use them to check whether adding an access item would potentially trigger a SOD violation. \nThis second option is a good way to prevent SOD violations from triggering at all. \n\nRefer to [Handling Policy Violations](https://documentation.sailpoint.com/saas/help/sod/policy-violations.html) for more information about SOD policy violations. \n"
"description": "Use this API to check for current \"separation of duties\" (SOD) policy violations as well as potential future SOD policy violations. \nWith SOD violation functionality in place, administrators can get information about current SOD policy violations and predict whether an access change will trigger new violations, which helps to prevent them from occurring at all. \n\n\"Separation of duties\" refers to the concept that people shouldn't have conflicting sets of access - all their access should be configured in a way that protects your organization's assets and data. \nFor example, people who record monetary transactions shouldn't be able to issue payment for those transactions.\nAny changes to major system configurations should be approved by someone other than the person requesting the change. \n\nOrganizations can use \"separation of duties\" (SOD) policies to enforce and track their internal security rules throughout their tenants.\nThese SOD policies limit each user's involvement in important processes and protects the organization from individuals gaining excessive access. \n\nOnce a SOD policy is in place, if an identity has conflicting access items, a SOD violation will trigger. \nThese violations are included in SOD violation reports that other users will see in emails at regular intervals if they're subscribed to the SOD policy.\nThe other users can then better help to enforce these SOD policies.\n\nAdministrators can use the SOD violations APIs to check a set of identities for any current SOD violations, and they can use them to check whether adding an access item would potentially trigger a SOD violation. \nThis second option is a good way to prevent SOD violations from triggering at all. \n\nRefer to [Handling Policy Violations](https://documentation.sailpoint.com/saas/help/sod/policy-violations.html) for more information about SOD policy violations.\n"
},
{
"name": "Source Usages",
@@ -238,7 +238,7 @@
},
{
"name": "Tagged Objects",
"description": "Use this API to implement object tagging functionality. \nWith object tagging functionality in place, any user in an organization can use tags as a way to group objects together and find them more quickly when the user searches IdentityNow. \n\nIn IdentityNow, users can search their tenants for information and add tags objects they find.\nTagging an object provides users with a way of grouping objects together and makes it easier to find these objects in the future. \n\nFor example, if a user is searching for an entitlement that grants a risky level of access to Active Directory, it's possible that the user may have to search through hundreds of entitlements to find the correct one. \nOnce the user finds that entitlement, the user can add a tag to the entitlement, \"AD_RISKY\" to make it easier to find the entitlement again.\nThe user can add the same tag to multiple objects the user wants to group together for an easy future search, and the user can also do so in bulk.\nWhen the user wants to find that tagged entitlement again, the user can search for \"tags:AD_RISKY\" to find all objects with that tag. \n\nWith the API, you can tag even more different object types than you can in IdentityNow (access profiles, entitlements, identities, and roles). \nYou can use the API to tag all these objects:\n\n- Access profiles \n\n- Applications \n\n- Certification campaigns\n\n- Entitlements\n\n- Identities \n\n- Roles \n\n- SOD (separation of duties) policies\n\n- Sources \n\nYou can also use the API to directly find, create, and manage tagged objects without using search queries. \n\nThere are limits to tags: \n\n- You can have up to 500 different tags in your tenant.\n\n- You can apply up to 30 tags to one object. \n\n- You can have up to 10,000 tag associations, pairings of 1 tag to 1 object, in your tenant. \n\nBecause of these limits, it is recommended that you work with your governance experts and security teams to establish a list of tags that are most expressive of governance objects and access managed by IdentityNow. \n\nThese are the types of information often expressed in tags: \n\n- Affected departments\n\n- Compliance and regulatory categories \n\n- Remediation urgency levels \n\n- Risk levels \n\nRefer to [Tagging Items in Search](https://documentation.sailpoint.com/saas/help/search/index.html?h=tags#tagging-items-in-search) for more information about tagging objects in IdentityNow. \n"
"description": "Use this API to implement object tagging functionality. \nWith object tagging functionality in place, any user in an organization can use tags as a way to group objects together and find them more quickly when the user searches IdentityNow. \n\nIn IdentityNow, users can search their tenants for information and add tags objects they find.\nTagging an object provides users with a way of grouping objects together and makes it easier to find these objects in the future. \n\nFor example, if a user is searching for an entitlement that grants a risky level of access to Active Directory, it's possible that the user may have to search through hundreds of entitlements to find the correct one. \nOnce the user finds that entitlement, the user can add a tag to the entitlement, \"AD_RISKY\" to make it easier to find the entitlement again.\nThe user can add the same tag to multiple objects the user wants to group together for an easy future search, and the user can also do so in bulk.\nWhen the user wants to find that tagged entitlement again, the user can search for \"tags:AD_RISKY\" to find all objects with that tag. \n\nWith the API, you can tag even more different object types than you can in IdentityNow (access profiles, entitlements, identities, and roles). \nYou can use the API to tag all these objects:\n\n- Access profiles \n\n- Applications \n\n- Certification campaigns\n\n- Entitlements\n\n- Identities \n\n- Roles \n\n- SOD (separation of duties) policies\n\n- Sources \n\nYou can also use the API to directly find, create, and manage tagged objects without using search queries. \n\nThere are limits to tags: \n\n- You can have up to 500 different tags in your tenant.\n\n- You can apply up to 30 tags to one object. \n\n- You can have up to 10,000 tag associations, pairings of 1 tag to 1 object, in your tenant. \n\nBecause of these limits, it is recommended that you work with your governance experts and security teams to establish a list of tags that are most expressive of governance objects and access managed by IdentityNow. \n\nThese are the types of information often expressed in tags: \n\n- Affected departments\n\n- Compliance and regulatory categories \n\n- Remediation urgency levels \n\n- Risk levels \n\nRefer to [Tagging Items in Search](https://documentation.sailpoint.com/saas/help/search/index.html?h=tags#tagging-items-in-search) for more information about tagging objects in IdentityNow.\n"
},
{
"name": "Task Management"
@@ -266,6 +266,10 @@
{
"name": "Workflows",
"description": "Workflows allow administrators to create custom automation scripts directly within IdentityNow. These automation scripts respond to [event triggers](https://developer.sailpoint.com/idn/docs/event-triggers#how-to-get-started-with-event-triggers) and perform a series of actions to perform tasks that are either too cumbersome or not available in the IdentityNow UI. Workflows can be configured via a graphical user interface within IdentityNow, or by creating and uploading a JSON formatted script to the Workflow service. The Workflows API collection provides the necessary functionality to create, manage, and test your workflows via REST.\n"
},
{
"name": "Icons",
"description": "Use this API to implement functionality related to object icons (application icons for example). \nWith this functionality in place, administrators can set or remove an icon for specific object type for use throughout IdentityNow.\n"
}
],
"security": [
@@ -277067,6 +277071,955 @@
}
}
}
},
"/icons/{objectType}/{objectId}": {
"put": {
"operationId": "setIcon",
"tags": [
"Icons"
],
"summary": "Update an icon",
"description": "This API endpoint updates an icon by object type and object id. A token with ORG_ADMIN authority is required to call this API.",
"parameters": [
{
"in": "path",
"name": "objectType",
"schema": {
"type": "string"
},
"required": true,
"description": "Object type. Available options ['application']",
"example": "application"
},
{
"in": "path",
"name": "objectId",
"schema": {
"type": "string"
},
"required": true,
"description": "Object id.",
"example": "a291e870-48c3-4953-b656-fb5ce2a93169"
}
],
"requestBody": {
"required": true,
"content": {
"multipart/form-data": {
"schema": {
"type": "object",
"required": [
"image"
],
"properties": {
"image": {
"type": "string",
"format": "binary",
"description": "file with icon. Allowed mime-types ['image/png', 'image/jpeg']",
"example": "\\x00\\x00\\x00\\x02"
}
}
}
}
}
},
"security": [
{
"UserContextAuth": []
}
],
"responses": {
"200": {
"description": "Icon updated",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"icon": {
"type": "string",
"description": "url to file with icon",
"example": ""
}
}
}
}
}
},
"400": {
"description": "Client Error - Returned if the request body is invalid.",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"detailCode": {
"type": "string",
"description": "Fine-grained error code providing more detail of the error.",
"example": "400.1 Bad Request Content"
},
"trackingId": {
"type": "string",
"description": "Unique tracking id for the error.",
"example": "e7eab60924f64aa284175b9fa3309599"
},
"messages": {
"type": "array",
"description": "Generic localized reason for error",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
},
"causes": {
"type": "array",
"description": "Plain-text descriptive reasons to provide additional detail to the text provided in the messages field",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
}
}
}
}
}
},
"401": {
"description": "Unauthorized - Returned if there is no authorization header, or if the JWT token is expired.",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"error": {
"description": "A message describing the error",
"example": "JWT validation failed: JWT is expired"
}
}
}
}
}
},
"403": {
"description": "Forbidden - Returned if the user you are running as, doesn't have access to this end-point.",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"detailCode": {
"type": "string",
"description": "Fine-grained error code providing more detail of the error.",
"example": "400.1 Bad Request Content"
},
"trackingId": {
"type": "string",
"description": "Unique tracking id for the error.",
"example": "e7eab60924f64aa284175b9fa3309599"
},
"messages": {
"type": "array",
"description": "Generic localized reason for error",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
},
"causes": {
"type": "array",
"description": "Plain-text descriptive reasons to provide additional detail to the text provided in the messages field",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
}
}
},
"examples": {
"403": {
"summary": "An example of a 403 response object",
"value": {
"detailCode": "403 Forbidden",
"trackingId": "b21b1f7ce4da4d639f2c62a57171b427",
"messages": [
{
"locale": "en-US",
"localeOrigin": "DEFAULT",
"text": "The server understood the request but refuses to authorize it."
}
]
}
}
}
}
}
},
"404": {
"description": "Not Found - returned if the request URL refers to a resource or object that does not exist",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"detailCode": {
"type": "string",
"description": "Fine-grained error code providing more detail of the error.",
"example": "400.1 Bad Request Content"
},
"trackingId": {
"type": "string",
"description": "Unique tracking id for the error.",
"example": "e7eab60924f64aa284175b9fa3309599"
},
"messages": {
"type": "array",
"description": "Generic localized reason for error",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
},
"causes": {
"type": "array",
"description": "Plain-text descriptive reasons to provide additional detail to the text provided in the messages field",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
}
}
},
"examples": {
"404": {
"summary": "An example of a 404 response object",
"value": {
"detailCode": "404 Not found",
"trackingId": "b21b1f7ce4da4d639f2c62a57171b427",
"messages": [
{
"locale": "en-US",
"localeOrigin": "DEFAULT",
"text": "The server did not find a current representation for the target resource."
}
]
}
}
}
}
}
},
"429": {
"description": "Too Many Requests - Returned in response to too many requests in a given period of time - rate limited. The Retry-After header in the response includes how long to wait before trying again.",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"message": {
"description": "A message describing the error",
"example": " Rate Limit Exceeded "
}
}
}
}
}
},
"500": {
"description": "Internal Server Error - Returned if there is an unexpected error.",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"detailCode": {
"type": "string",
"description": "Fine-grained error code providing more detail of the error.",
"example": "400.1 Bad Request Content"
},
"trackingId": {
"type": "string",
"description": "Unique tracking id for the error.",
"example": "e7eab60924f64aa284175b9fa3309599"
},
"messages": {
"type": "array",
"description": "Generic localized reason for error",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
},
"causes": {
"type": "array",
"description": "Plain-text descriptive reasons to provide additional detail to the text provided in the messages field",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
}
}
},
"examples": {
"500": {
"summary": "An example of a 500 response object",
"value": {
"detailCode": "500.0 Internal Fault",
"trackingId": "b21b1f7ce4da4d639f2c62a57171b427",
"messages": [
{
"locale": "en-US",
"localeOrigin": "DEFAULT",
"text": "An internal fault occurred."
}
]
}
}
}
}
}
}
}
},
"delete": {
"operationId": "deleteIcon",
"tags": [
"Icons"
],
"summary": "Delete an icon",
"description": "This API endpoint delete an icon by object type and object id. A token with ORG_ADMIN authority is required to call this API.",
"parameters": [
{
"in": "path",
"name": "objectType",
"schema": {
"type": "string"
},
"required": true,
"description": "Object type. Available options ['application']",
"example": "application"
},
{
"in": "path",
"name": "objectId",
"schema": {
"type": "string"
},
"required": true,
"description": "Object id.",
"example": "a291e870-48c3-4953-b656-fb5ce2a93169"
}
],
"security": [
{
"UserContextAuth": []
}
],
"responses": {
"204": {
"description": "No content - indicates the request was successful but there is no content to be returned in the response."
},
"400": {
"description": "Client Error - Returned if the request body is invalid.",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"detailCode": {
"type": "string",
"description": "Fine-grained error code providing more detail of the error.",
"example": "400.1 Bad Request Content"
},
"trackingId": {
"type": "string",
"description": "Unique tracking id for the error.",
"example": "e7eab60924f64aa284175b9fa3309599"
},
"messages": {
"type": "array",
"description": "Generic localized reason for error",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
},
"causes": {
"type": "array",
"description": "Plain-text descriptive reasons to provide additional detail to the text provided in the messages field",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
}
}
}
}
}
},
"401": {
"description": "Unauthorized - Returned if there is no authorization header, or if the JWT token is expired.",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"error": {
"description": "A message describing the error",
"example": "JWT validation failed: JWT is expired"
}
}
}
}
}
},
"403": {
"description": "Forbidden - Returned if the user you are running as, doesn't have access to this end-point.",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"detailCode": {
"type": "string",
"description": "Fine-grained error code providing more detail of the error.",
"example": "400.1 Bad Request Content"
},
"trackingId": {
"type": "string",
"description": "Unique tracking id for the error.",
"example": "e7eab60924f64aa284175b9fa3309599"
},
"messages": {
"type": "array",
"description": "Generic localized reason for error",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
},
"causes": {
"type": "array",
"description": "Plain-text descriptive reasons to provide additional detail to the text provided in the messages field",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
}
}
},
"examples": {
"403": {
"summary": "An example of a 403 response object",
"value": {
"detailCode": "403 Forbidden",
"trackingId": "b21b1f7ce4da4d639f2c62a57171b427",
"messages": [
{
"locale": "en-US",
"localeOrigin": "DEFAULT",
"text": "The server understood the request but refuses to authorize it."
}
]
}
}
}
}
}
},
"404": {
"description": "Not Found - returned if the request URL refers to a resource or object that does not exist",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"detailCode": {
"type": "string",
"description": "Fine-grained error code providing more detail of the error.",
"example": "400.1 Bad Request Content"
},
"trackingId": {
"type": "string",
"description": "Unique tracking id for the error.",
"example": "e7eab60924f64aa284175b9fa3309599"
},
"messages": {
"type": "array",
"description": "Generic localized reason for error",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
},
"causes": {
"type": "array",
"description": "Plain-text descriptive reasons to provide additional detail to the text provided in the messages field",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
}
}
},
"examples": {
"404": {
"summary": "An example of a 404 response object",
"value": {
"detailCode": "404 Not found",
"trackingId": "b21b1f7ce4da4d639f2c62a57171b427",
"messages": [
{
"locale": "en-US",
"localeOrigin": "DEFAULT",
"text": "The server did not find a current representation for the target resource."
}
]
}
}
}
}
}
},
"429": {
"description": "Too Many Requests - Returned in response to too many requests in a given period of time - rate limited. The Retry-After header in the response includes how long to wait before trying again.",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"message": {
"description": "A message describing the error",
"example": " Rate Limit Exceeded "
}
}
}
}
}
},
"500": {
"description": "Internal Server Error - Returned if there is an unexpected error.",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"detailCode": {
"type": "string",
"description": "Fine-grained error code providing more detail of the error.",
"example": "400.1 Bad Request Content"
},
"trackingId": {
"type": "string",
"description": "Unique tracking id for the error.",
"example": "e7eab60924f64aa284175b9fa3309599"
},
"messages": {
"type": "array",
"description": "Generic localized reason for error",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
},
"causes": {
"type": "array",
"description": "Plain-text descriptive reasons to provide additional detail to the text provided in the messages field",
"items": {
"type": "object",
"properties": {
"locale": {
"type": "string",
"description": "The locale for the message text, a BCP 47 language tag.",
"example": "en-US",
"nullable": true
},
"localeOrigin": {
"type": "string",
"enum": [
"DEFAULT",
"REQUEST",
null
],
"description": "An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.",
"example": "DEFAULT",
"nullable": true
},
"text": {
"type": "string",
"description": "Actual text of the error message in the indicated locale.",
"example": "The request was syntactically correct but its content is semantically invalid."
}
}
}
}
}
},
"examples": {
"500": {
"summary": "An example of a 500 response object",
"value": {
"detailCode": "500.0 Internal Fault",
"trackingId": "b21b1f7ce4da4d639f2c62a57171b427",
"messages": [
{
"locale": "en-US",
"localeOrigin": "DEFAULT",
"text": "An internal fault occurred."
}
]
}
}
}
}
}
}
}
}
}
}
}

684
dereferenced/deref-sailpoint-api.beta.yaml
View File

@@ -972,6 +972,10 @@ tags:
- name: Workflows
description: |
Workflows allow administrators to create custom automation scripts directly within IdentityNow. These automation scripts respond to [event triggers](https://developer.sailpoint.com/idn/docs/event-triggers#how-to-get-started-with-event-triggers) and perform a series of actions to perform tasks that are either too cumbersome or not available in the IdentityNow UI. Workflows can be configured via a graphical user interface within IdentityNow, or by creating and uploading a JSON formatted script to the Workflow service. The Workflows API collection provides the necessary functionality to create, manage, and test your workflows via REST.
- name: Icons
description: |
Use this API to implement functionality related to object icons (application icons for example).
With this functionality in place, administrators can set or remove an icon for specific object type for use throughout IdentityNow.
security:
- UserContextAuth: []
components:
@@ -210013,3 +210017,683 @@ paths:
- locale: en-US
localeOrigin: DEFAULT
text: An internal fault occurred.
'/icons/{objectType}/{objectId}':
put:
operationId: setIcon
tags:
- Icons
summary: Update an icon
description: This API endpoint updates an icon by object type and object id. A token with ORG_ADMIN authority is required to call this API.
parameters:
- in: path
name: objectType
schema:
type: string
required: true
description: 'Object type. Available options [''application'']'
example: application
- in: path
name: objectId
schema:
type: string
required: true
description: Object id.
example: a291e870-48c3-4953-b656-fb5ce2a93169
requestBody:
required: true
content:
multipart/form-data:
schema:
type: object
required:
- image
properties:
image:
type: string
format: binary
description: 'file with icon. Allowed mime-types [''image/png'', ''image/jpeg'']'
example: \x00\x00\x00\x02
security:
- UserContextAuth: []
responses:
'200':
description: Icon updated
content:
application/json:
schema:
type: object
properties:
icon:
type: string
description: url to file with icon
example: ''
'400':
description: Client Error - Returned if the request body is invalid.
content:
application/json:
schema:
type: object
properties:
detailCode:
type: string
description: Fine-grained error code providing more detail of the error.
example: 400.1 Bad Request Content
trackingId:
type: string
description: Unique tracking id for the error.
example: e7eab60924f64aa284175b9fa3309599
messages:
type: array
description: Generic localized reason for error
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
causes:
type: array
description: Plain-text descriptive reasons to provide additional detail to the text provided in the messages field
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
'401':
description: 'Unauthorized - Returned if there is no authorization header, or if the JWT token is expired.'
content:
application/json:
schema:
type: object
properties:
error:
description: A message describing the error
example: 'JWT validation failed: JWT is expired'
'403':
description: 'Forbidden - Returned if the user you are running as, doesn''t have access to this end-point.'
content:
application/json:
schema:
type: object
properties:
detailCode:
type: string
description: Fine-grained error code providing more detail of the error.
example: 400.1 Bad Request Content
trackingId:
type: string
description: Unique tracking id for the error.
example: e7eab60924f64aa284175b9fa3309599
messages:
type: array
description: Generic localized reason for error
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
causes:
type: array
description: Plain-text descriptive reasons to provide additional detail to the text provided in the messages field
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
examples:
'403':
summary: An example of a 403 response object
value:
detailCode: 403 Forbidden
trackingId: b21b1f7ce4da4d639f2c62a57171b427
messages:
- locale: en-US
localeOrigin: DEFAULT
text: The server understood the request but refuses to authorize it.
'404':
description: Not Found - returned if the request URL refers to a resource or object that does not exist
content:
application/json:
schema:
type: object
properties:
detailCode:
type: string
description: Fine-grained error code providing more detail of the error.
example: 400.1 Bad Request Content
trackingId:
type: string
description: Unique tracking id for the error.
example: e7eab60924f64aa284175b9fa3309599
messages:
type: array
description: Generic localized reason for error
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
causes:
type: array
description: Plain-text descriptive reasons to provide additional detail to the text provided in the messages field
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
examples:
'404':
summary: An example of a 404 response object
value:
detailCode: 404 Not found
trackingId: b21b1f7ce4da4d639f2c62a57171b427
messages:
- locale: en-US
localeOrigin: DEFAULT
text: The server did not find a current representation for the target resource.
'429':
description: Too Many Requests - Returned in response to too many requests in a given period of time - rate limited. The Retry-After header in the response includes how long to wait before trying again.
content:
application/json:
schema:
type: object
properties:
message:
description: A message describing the error
example: ' Rate Limit Exceeded '
'500':
description: Internal Server Error - Returned if there is an unexpected error.
content:
application/json:
schema:
type: object
properties:
detailCode:
type: string
description: Fine-grained error code providing more detail of the error.
example: 400.1 Bad Request Content
trackingId:
type: string
description: Unique tracking id for the error.
example: e7eab60924f64aa284175b9fa3309599
messages:
type: array
description: Generic localized reason for error
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
causes:
type: array
description: Plain-text descriptive reasons to provide additional detail to the text provided in the messages field
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
examples:
'500':
summary: An example of a 500 response object
value:
detailCode: 500.0 Internal Fault
trackingId: b21b1f7ce4da4d639f2c62a57171b427
messages:
- locale: en-US
localeOrigin: DEFAULT
text: An internal fault occurred.
delete:
operationId: deleteIcon
tags:
- Icons
summary: Delete an icon
description: This API endpoint delete an icon by object type and object id. A token with ORG_ADMIN authority is required to call this API.
parameters:
- in: path
name: objectType
schema:
type: string
required: true
description: 'Object type. Available options [''application'']'
example: application
- in: path
name: objectId
schema:
type: string
required: true
description: Object id.
example: a291e870-48c3-4953-b656-fb5ce2a93169
security:
- UserContextAuth: []
responses:
'204':
description: No content - indicates the request was successful but there is no content to be returned in the response.
'400':
description: Client Error - Returned if the request body is invalid.
content:
application/json:
schema:
type: object
properties:
detailCode:
type: string
description: Fine-grained error code providing more detail of the error.
example: 400.1 Bad Request Content
trackingId:
type: string
description: Unique tracking id for the error.
example: e7eab60924f64aa284175b9fa3309599
messages:
type: array
description: Generic localized reason for error
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
causes:
type: array
description: Plain-text descriptive reasons to provide additional detail to the text provided in the messages field
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
'401':
description: 'Unauthorized - Returned if there is no authorization header, or if the JWT token is expired.'
content:
application/json:
schema:
type: object
properties:
error:
description: A message describing the error
example: 'JWT validation failed: JWT is expired'
'403':
description: 'Forbidden - Returned if the user you are running as, doesn''t have access to this end-point.'
content:
application/json:
schema:
type: object
properties:
detailCode:
type: string
description: Fine-grained error code providing more detail of the error.
example: 400.1 Bad Request Content
trackingId:
type: string
description: Unique tracking id for the error.
example: e7eab60924f64aa284175b9fa3309599
messages:
type: array
description: Generic localized reason for error
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
causes:
type: array
description: Plain-text descriptive reasons to provide additional detail to the text provided in the messages field
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
examples:
'403':
summary: An example of a 403 response object
value:
detailCode: 403 Forbidden
trackingId: b21b1f7ce4da4d639f2c62a57171b427
messages:
- locale: en-US
localeOrigin: DEFAULT
text: The server understood the request but refuses to authorize it.
'404':
description: Not Found - returned if the request URL refers to a resource or object that does not exist
content:
application/json:
schema:
type: object
properties:
detailCode:
type: string
description: Fine-grained error code providing more detail of the error.
example: 400.1 Bad Request Content
trackingId:
type: string
description: Unique tracking id for the error.
example: e7eab60924f64aa284175b9fa3309599
messages:
type: array
description: Generic localized reason for error
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
causes:
type: array
description: Plain-text descriptive reasons to provide additional detail to the text provided in the messages field
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
examples:
'404':
summary: An example of a 404 response object
value:
detailCode: 404 Not found
trackingId: b21b1f7ce4da4d639f2c62a57171b427
messages:
- locale: en-US
localeOrigin: DEFAULT
text: The server did not find a current representation for the target resource.
'429':
description: Too Many Requests - Returned in response to too many requests in a given period of time - rate limited. The Retry-After header in the response includes how long to wait before trying again.
content:
application/json:
schema:
type: object
properties:
message:
description: A message describing the error
example: ' Rate Limit Exceeded '
'500':
description: Internal Server Error - Returned if there is an unexpected error.
content:
application/json:
schema:
type: object
properties:
detailCode:
type: string
description: Fine-grained error code providing more detail of the error.
example: 400.1 Bad Request Content
trackingId:
type: string
description: Unique tracking id for the error.
example: e7eab60924f64aa284175b9fa3309599
messages:
type: array
description: Generic localized reason for error
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
causes:
type: array
description: Plain-text descriptive reasons to provide additional detail to the text provided in the messages field
items:
type: object
properties:
locale:
type: string
description: 'The locale for the message text, a BCP 47 language tag.'
example: en-US
nullable: true
localeOrigin:
type: string
enum:
- DEFAULT
- REQUEST
- null
description: 'An indicator of how the locale was selected. *DEFAULT* means the locale is the system default. *REQUEST* means the locale was selected from the request context (i.e., best match based on the *Accept-Language* header). Additional values may be added in the future without notice.'
example: DEFAULT
nullable: true
text:
type: string
description: Actual text of the error message in the indicated locale.
example: The request was syntactically correct but its content is semantically invalid.
examples:
'500':
summary: An example of a 500 response object
value:
detailCode: 500.0 Internal Fault
trackingId: b21b1f7ce4da4d639f2c62a57171b427
messages:
- locale: en-US
localeOrigin: DEFAULT
text: An internal fault occurred.

26
dereferenced/deref-sailpoint-api.v3.json
View File

@@ -139,7 +139,7 @@
},
{
"name": "Reports Data Extraction",
"description": "Use this API to implement reports lifecycle managing and monitoring.\nWith this functionality in place, users can run reports, view their results, and cancel reports in progress. \nThis can be potentially helpful for auditing purposes. \n"
"description": "Use this API to implement reports lifecycle managing and monitoring.\nWith this functionality in place, users can run reports, view their results, and cancel reports in progress. \nThis can be potentially helpful for auditing purposes.\n"
},
{
"name": "Requestable Objects",
@@ -175,7 +175,7 @@
},
{
"name": "SOD Violations",
"description": "Use this API to check for current \"separation of duties\" (SOD) policy violations as well as potential future SOD policy violations. \nWith SOD violation functionality in place, administrators can get information about current SOD policy violations and predict whether an access change will trigger new violations, which helps to prevent them from occurring at all. \n\n\"Separation of duties\" refers to the concept that people shouldn't have conflicting sets of access - all their access should be configured in a way that protects your organization's assets and data. \nFor example, people who record monetary transactions shouldn't be able to issue payment for those transactions.\nAny changes to major system configurations should be approved by someone other than the person requesting the change. \n\nOrganizations can use \"separation of duties\" (SOD) policies to enforce and track their internal security rules throughout their tenants.\nThese SOD policies limit each user's involvement in important processes and protects the organization from individuals gaining excessive access. \n\nOnce a SOD policy is in place, if an identity has conflicting access items, a SOD violation will trigger. \nThese violations are included in SOD violation reports that other users will see in emails at regular intervals if they're subscribed to the SOD policy.\nThe other users can then better help to enforce these SOD policies.\n\nAdministrators can use the SOD violations APIs to check a set of identities for any current SOD violations, and they can use them to check whether adding an access item would potentially trigger a SOD violation. \nThis second option is a good way to prevent SOD violations from triggering at all. \n\nRefer to [Handling Policy Violations](https://documentation.sailpoint.com/saas/help/sod/policy-violations.html) for more information about SOD policy violations. \n"
"description": "Use this API to check for current \"separation of duties\" (SOD) policy violations as well as potential future SOD policy violations. \nWith SOD violation functionality in place, administrators can get information about current SOD policy violations and predict whether an access change will trigger new violations, which helps to prevent them from occurring at all. \n\n\"Separation of duties\" refers to the concept that people shouldn't have conflicting sets of access - all their access should be configured in a way that protects your organization's assets and data. \nFor example, people who record monetary transactions shouldn't be able to issue payment for those transactions.\nAny changes to major system configurations should be approved by someone other than the person requesting the change. \n\nOrganizations can use \"separation of duties\" (SOD) policies to enforce and track their internal security rules throughout their tenants.\nThese SOD policies limit each user's involvement in important processes and protects the organization from individuals gaining excessive access. \n\nOnce a SOD policy is in place, if an identity has conflicting access items, a SOD violation will trigger. \nThese violations are included in SOD violation reports that other users will see in emails at regular intervals if they're subscribed to the SOD policy.\nThe other users can then better help to enforce these SOD policies.\n\nAdministrators can use the SOD violations APIs to check a set of identities for any current SOD violations, and they can use them to check whether adding an access item would potentially trigger a SOD violation. \nThis second option is a good way to prevent SOD violations from triggering at all. \n\nRefer to [Handling Policy Violations](https://documentation.sailpoint.com/saas/help/sod/policy-violations.html) for more information about SOD policy violations.\n"
},
{
"name": "Source Usages",
@@ -187,7 +187,7 @@
},
{
"name": "Tagged Objects",
"description": "Use this API to implement object tagging functionality. \nWith object tagging functionality in place, any user in an organization can use tags as a way to group objects together and find them more quickly when the user searches IdentityNow. \n\nIn IdentityNow, users can search their tenants for information and add tags objects they find.\nTagging an object provides users with a way of grouping objects together and makes it easier to find these objects in the future. \n\nFor example, if a user is searching for an entitlement that grants a risky level of access to Active Directory, it's possible that the user may have to search through hundreds of entitlements to find the correct one. \nOnce the user finds that entitlement, the user can add a tag to the entitlement, \"AD_RISKY\" to make it easier to find the entitlement again.\nThe user can add the same tag to multiple objects the user wants to group together for an easy future search, and the user can also do so in bulk.\nWhen the user wants to find that tagged entitlement again, the user can search for \"tags:AD_RISKY\" to find all objects with that tag. \n\nWith the API, you can tag even more different object types than you can in IdentityNow (access profiles, entitlements, identities, and roles). \nYou can use the API to tag all these objects:\n\n- Access profiles \n\n- Applications \n\n- Certification campaigns\n\n- Entitlements\n\n- Identities \n\n- Roles \n\n- SOD (separation of duties) policies\n\n- Sources \n\nYou can also use the API to directly find, create, and manage tagged objects without using search queries. \n\nThere are limits to tags: \n\n- You can have up to 500 different tags in your tenant.\n\n- You can apply up to 30 tags to one object. \n\n- You can have up to 10,000 tag associations, pairings of 1 tag to 1 object, in your tenant. \n\nBecause of these limits, it is recommended that you work with your governance experts and security teams to establish a list of tags that are most expressive of governance objects and access managed by IdentityNow. \n\nThese are the types of information often expressed in tags: \n\n- Affected departments\n\n- Compliance and regulatory categories \n\n- Remediation urgency levels \n\n- Risk levels \n\nRefer to [Tagging Items in Search](https://documentation.sailpoint.com/saas/help/search/index.html?h=tags#tagging-items-in-search) for more information about tagging objects in IdentityNow. \n"
"description": "Use this API to implement object tagging functionality. \nWith object tagging functionality in place, any user in an organization can use tags as a way to group objects together and find them more quickly when the user searches IdentityNow. \n\nIn IdentityNow, users can search their tenants for information and add tags objects they find.\nTagging an object provides users with a way of grouping objects together and makes it easier to find these objects in the future. \n\nFor example, if a user is searching for an entitlement that grants a risky level of access to Active Directory, it's possible that the user may have to search through hundreds of entitlements to find the correct one. \nOnce the user finds that entitlement, the user can add a tag to the entitlement, \"AD_RISKY\" to make it easier to find the entitlement again.\nThe user can add the same tag to multiple objects the user wants to group together for an easy future search, and the user can also do so in bulk.\nWhen the user wants to find that tagged entitlement again, the user can search for \"tags:AD_RISKY\" to find all objects with that tag. \n\nWith the API, you can tag even more different object types than you can in IdentityNow (access profiles, entitlements, identities, and roles). \nYou can use the API to tag all these objects:\n\n- Access profiles \n\n- Applications \n\n- Certification campaigns\n\n- Entitlements\n\n- Identities \n\n- Roles \n\n- SOD (separation of duties) policies\n\n- Sources \n\nYou can also use the API to directly find, create, and manage tagged objects without using search queries. \n\nThere are limits to tags: \n\n- You can have up to 500 different tags in your tenant.\n\n- You can apply up to 30 tags to one object. \n\n- You can have up to 10,000 tag associations, pairings of 1 tag to 1 object, in your tenant. \n\nBecause of these limits, it is recommended that you work with your governance experts and security teams to establish a list of tags that are most expressive of governance objects and access managed by IdentityNow. \n\nThese are the types of information often expressed in tags: \n\n- Affected departments\n\n- Compliance and regulatory categories \n\n- Remediation urgency levels \n\n- Risk levels \n\nRefer to [Tagging Items in Search](https://documentation.sailpoint.com/saas/help/search/index.html?h=tags#tagging-items-in-search) for more information about tagging objects in IdentityNow.\n"
},
{
"name": "Transforms",
@@ -22849,9 +22849,7 @@
"description": "This API endpoint returns a list of branding items.\n\nA token with API, ORG_ADMIN authority is required to call this API.",
"security": [
{
"UserContextAuth": [
"idn:branding:read"
]
"UserContextAuth": []
}
],
"responses": {
@@ -23302,9 +23300,7 @@
},
"security": [
{
"UserContextAuth": [
"idn:branding:write"
]
"UserContextAuth": []
}
],
"responses": {
@@ -23696,9 +23692,7 @@
"description": "This API endpoint retrieves information for an existing branding item by name.\nA token with API, ORG_ADMIN authority is required to call this API.",
"security": [
{
"UserContextAuth": [
"idn:branding:read"
]
"UserContextAuth": []
}
],
"parameters": [
@@ -24270,9 +24264,7 @@
},
"security": [
{
"UserContextAuth": [
"idn:branding:write"
]
"UserContextAuth": []
}
],
"responses": {
@@ -24762,9 +24754,7 @@
"description": "This API endpoint delete information for an existing branding item by name.\nA token with API, ORG_ADMIN authority is required to call this API.",
"security": [
{
"UserContextAuth": [
"idn:branding:write"
]
"UserContextAuth": []
}
],
"parameters": [

15
dereferenced/deref-sailpoint-api.v3.yaml
View File

@@ -18014,8 +18014,7 @@ paths:
A token with API, ORG_ADMIN authority is required to call this API.
security:
- UserContextAuth:
- 'idn:branding:read'
- UserContextAuth: []
responses:
'200':
description: A list of branding items.
@@ -18347,8 +18346,7 @@ paths:
description: png file with logo
example: \x00\x00\x00\x02
security:
- UserContextAuth:
- 'idn:branding:write'
- UserContextAuth: []
responses:
'201':
description: Branding item created
@@ -18635,8 +18633,7 @@ paths:
This API endpoint retrieves information for an existing branding item by name.
A token with API, ORG_ADMIN authority is required to call this API.
security:
- UserContextAuth:
- 'idn:branding:read'
- UserContextAuth: []
parameters:
- in: path
name: name
@@ -19055,8 +19052,7 @@ paths:
description: png file with logo
example: \x00\x00\x00\x02
security:
- UserContextAuth:
- 'idn:branding:write'
- UserContextAuth: []
responses:
'200':
description: Branding item updated
@@ -19415,8 +19411,7 @@ paths:
This API endpoint delete information for an existing branding item by name.
A token with API, ORG_ADMIN authority is required to call this API.
security:
- UserContextAuth:
- 'idn:branding:write'
- UserContextAuth: []
parameters:
- in: path
name: name

9142
postman/collections/sailpoint-api-beta.json
View File

File diff suppressed because one or more lines are too long

1698
postman/collections/sailpoint-api-nerm.json
View File

File diff suppressed because one or more lines are too long

5006
postman/collections/sailpoint-api-v3.json
View File

File diff suppressed because one or more lines are too long