# SailPoint Web Services SaaS Connector Documentation

> Web Services SaaS Connector Documentation

# Documentation

# Configuration Parameters

For the Web Services source you can configure the values of the following attributes using the SailPoint REST API. For the usage of the SailPoint REST APIs for the following attributes and keys, refer to:

- API to get source details - [list-sources](<https://developer.sailpoint.com/docs/api/list-sources-v-1/>)
- API to get a specific source's current schema details - [list-schemas](<https://developer.sailpoint.com/docs/api/get-source-schemas-v-1/>)
- API to add a new schema attribute to a source - [create-schema](<https://developer.sailpoint.com/docs/api/create-source-schema-v-1/>)
- [SailPoint REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>)

## createAccountWithEntReq

By default, the Web Services source creates an account for a `Create Account` operation and then adds the entitlements one by one. For example, if there are three entitlements (Role, Group, Profile), the source executes three requests and three API calls are sent.

Adding the `createAccountWithEntReq` attribute merges all the entitlement requests in a single API call. Use the `createAccountWithEntReq` attribute key with the value `true` to enable the functionality of sending entitlements with create account in a single request to the managed system.

Default value: `false`

## possibleHttpErrors

When an API endpoint does not send expected error codes to flag failure conditions, the connector can be configured with all possible HTTP error codes and messages that the API endpoint returns, which result in failure of operations.

Use the `possibleHttpErrors` attribute with `["errorCodes","errorMessages"]` as the value.

Occasionally, the Web Services connector returns the HTTP status code `200` but the response payload may contain errors. In this case, the connector must fail the request, or an OAuth token generation must try to regenerate the token.

You can also configure these possible HTTP error codes and messages to specify invalid or expired token errors. In this case, the connector regenerates and saves the token for OAuth 2.0 authentication, then retries the operation with the newly generated access token.

> [!NOTE]
>
> This flag is not applicable for child endpoints.

## objectNotFoundErrorMsg

Based on the error message list, the source decides whether to display the `objectNotFoundErrorMsg` error. For example, you can create an entry for `objectNotFoundErrorMsg` with a custom error message to identify multiple exceptions by setting the `objectNotFoundErrorMsg` attribute key with `["404: Not Found", "404"]` as the value.

## updateAttrWithChangePassword

To enable single requests for change password and update operations, use the `updateAttrWithChangePassword` attribute key with `true` as a value.

If the value of the `updateAttrWithChangePassword` attribute is `true` in the source and the plan contains no attribute request named "password" (change password), then the specific Update operation type endpoint is invoked.

Setting the value of the `updateAttrWithChangePassword` attribute to `true` does not include requests for add or remove entitlements. These requests are executed independently.

## disableCookies

By default, the Web Services source supports cookies. Disable cookies by adding the `disableCookies` attribute key with `true` as a value. This attribute is not applicable for the authentication API call operation.

## addRemoveEntInSingleReq

Add or remove multiple entitlements such as Role, Permissions, or Profile. To send multiple entitlement requests in a single request to the managed system, set the value of the `addRemoveEntInSingleReq` parameter to `true` as shown in the following example:

```xml
<entry key="addRemoveEntInSingleReq">
    <value>
        <Boolean>true</Boolean>
    </value>
</entry>
```

If `addRemoveEntInSingleReq` is set to `true`, then the payload for entitlements must also be set as shown in the following example:

```text
{"group_id" : $plan.groups$,
"permission":$plan.permission$,
"roles": $plan.roles$
}
```

## skipGetObjectInCreate

The Web Services SaaS connector supports the `skipGetObjectInCreate` attribute (Boolean) to skip the `getObject` call if it is present during the Create provisioning operation.

## deleteStatus

This attribute marks whether an object is deleted during delta aggregation. To set the value of `deleteStatus`, set the value as shown in the following example:

```xml
<entry key="deleteStatus" value="deleted=true"/>
```

## retryDelay

By default, the connector waits 30 seconds between automatic retries for HTTP 429 and HTTP 503 errors. The connector performs a maximum of three retries per request. The connector determines the delay in the following order:

- `retryDelay` - If this attribute is set to a positive integer on the source, the connector uses this fixed value first.
- `Retry-After` header - If no valid `retryDelay` exists, the connector uses the numeric value (in seconds) provided in the `Retry-After` header.
- Fallback - If neither of the previous values is valid or present, the connector defaults back to 30 seconds.

> [!NOTE]
>
> Additional configurable attributes are available beyond those documented here. Refer to the SailPoint REST API links above to list a source's current configuration and confirm available attribute keys before setting a new one.

## Configuration for Response

When configuring the Web Services source, map the schema attribute as follows for JSON and XML.

### JSON Response Configuration

Single endpoint - In a JSON response, all the attributes can be mapped as follows, considering the Root Path as `$.list`:

```text
Id = id
displayName = displayName
username = jive.username
enabled = jive.enabled
emails = emails[*].value
```

Multiple endpoints - Refer to the following response example for the first and second endpoints:

| Type | Response Example | Response Mapping |
| --- | --- | --- |
| First endpoint | `{"meta": {...}, "resources": ["01dcc3dd-5b72-4fb2-a43b-424e092bd6af", "032b704e-1467-48b3-ad70-29a04f1a20ab", "042ab092-918f-4ed3-97eb-196fbe917e77"], "errors": []}` | Response Attribute Mapping: `uid = $`. Root Path: `$.resources.*` |
| Second endpoint | Context URL - `/users/entities/users/v1?ids=$response.uid$`. Example: `{"meta": {...}, "resources": [{"uid": "john.doe@santander.us", "firstName": "John", "lastName": "Doe", "uuid": "01dcc3dd-5b72-4fb2-a43b-424e092bd6af", "customer": "81971f9d094d494bae5a5fd97052509f"}], "errors": []}` | Response Attribute Mapping: `firstName = $.resources[0].firstName`, `lastName = $.resources[0].lastName`. Root Path: not required |

Parsing JSON array - The following is an example for parsing a JSON array:

```json
[1,10,21,31,46,89,90,67,88,98,101]
```

The response mapping for the above example is:

- Response Attribute Mapping (`id` is an attribute in the schema): `id = $`
- Root Path: `$.*`

### XML Response Configuration

Example 1 - XML response for mapping:

```xml
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns="urn:partner.soap.sforce.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sf="urn:sobject.partner.soap.sforce.com">
 <soapenv:Header>
      .....
 </soapenv:Header>
 <soapenv:Body>
    <queryResponse>
       <result xsi:type="QueryResult">
         <done>true</done>
         <queryLocator xsi:nil="true"/>
         <records xsi:type="sf:sObject">
           <sf:type>User</sf:type>
           <sf:Id>123456</sf:Id>
           <sf:Alias>Alias</sf:Alias>
           <sf:City xsi:nil="true"/>
           <sf:CommunityNickname>CName1</sf:CommunityNickname>
           <sf:Email>test@test.com</sf:Email>
           <sf:IsActive>false</sf:IsActive>
           <sf:Username>test@test.com</sf:Username>
           <sf:FirstName>Test</sf:FirstName>
           <sf:LastName>Test</sf:LastName>
         </records>
        <size>1</size>
         </result>
     </queryResponse>
   </soapenv:Body>
</soapenv:Envelope>
```

Example 2 - XML response for mapping:

```xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><userList id="5457373">
<name>DillardsEveryone</name>
  <memberList>
    <listMember>example@example.com</listMember>
    <listMember>gage5.test5@test5.dillards.com</listMember>
  </memberList>
</userList>
```

For more specific examples of the JSON and XML format responses or inputs for the supported fields or operations on the Web Services source, refer to [Operations Reference](<https://documentation.sailpoint.com/connectors/web_services/saas/help/operations_reference.html>).

# Configuring Web Services SaaS for Integration

> [!WARNING]
>
> When configuring the source, do not hard code sensitive data. If sensitive data is hard coded, it can lead to that data being exposed when moving to a production environment. SailPoint recommends putting sensitive information in the encrypted attribute value list in the application XML and then using the encrypted variable name when configuring the source. For example, if you want to add the custom variable `Custom_Variable` in the encrypted list, append the variable name in the following list: `<entry key="encrypted" value="accesstoken, refresh_token, Custom_Variable"/>`

This section describes the various configurations to be performed to support the following features.

## Pass-Through Authentication

Configure Pass-Through Authentication on existing Web Services.

1. On the **Additional Settings** page, select the **Get Object Required for Pass-Through Authentication** checkbox.

   > **Notes**
   >
   > - When selected, it executes the Get Object operation to verify if the entered Username (considered an identity attribute) is present on the managed system or not.
   > - When deselected, it skips the Get Object operation and the Pass-Through Authentication operation must have response mapping with account object schema attributes.
2. (Optional) If you need to configure error messages for Pass-Through Authentication, use the following entry keys:

   - `objectNotFoundErrorMsg`
   - `authenticationFailedErrorMsg`
   - `expiredPasswordErrorMsg`

The following process is an example to configure Pass-Through Configuration.

### Pass-Through Authentication General Information

1. In the **Operation Name** field, enter `Pass-Through Authentication` as the operation name.
2. From the **Operation Type** dropdown list, select **Pass-Through Authentication**.
3. In the **Authentication URL** field, enter the URL specific to the Pass-Through Authentication.
4. In the **HTTP Method** dropdown list, select **POST**.

### Pass-Through Authentication Header and Body

The HTTP body is used to post data with a request. The Header has the data keys and their corresponding values. These key-value pairs are sent as part of the Header in the HTTP Request.

1. Under the **Header** tab, enter the following **Key**/**Value** pairs:

   - **Key** = `SOAPAction`, **Value** = `urn:partner.soap.sforce.com/Soap/queryReq`
   - **Key** = `Content-Type`, **Value** = `text/xml`

   Refer to [Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html#header>) for more information.
2. Under the **Body** tab, select the **Raw** radio button.
3. In the **Body** field, enter the XML payload for the Pass-Through Authentication.

   > **Note**
   >
   > The Body has two types: Form Data and Raw. XML format does not support Form Data.

   > **XML Payload Example**
   >
   > ```xml
   > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   > xmlns:urn=urn:partner.soap.sforce.com">
   >     <soapenv:Header>
   >         <urn:LoginScopeHeader>
   >             <urn:organizationId></urn:organizationId>
   >             <urn:portalId></urn:portalId>
   >         </urn:loginScopeHeader>
   >     </soapenv:Header>
   >     <soapenv:Body>
   >         <urn:login>
   >             <urn:username>$authenticate.username$</urn:username>
   >             <urn:password>$authenticate.password$</urn:password>
   >         </urn:login>
   >     </soapenv:Body>
   > </soapenv:Envelope>
   > ```

   Refer to [Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html#body>) for more information.

### Pass-Through Authentication Response Information

Refer to [Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html#response-information>) for more information.

The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.

1. In the **Root Path** field, enter `//ns:userInfo`.
2. In the **Success Code** field, enter `2**`.

### Pass-Through Authentication Response Mapping

Refer to [Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html#response-mapping>) for more information.

Enter the following **Schema Attribute** and **Attribute Path** pairs:

- **Schema Attribute** = `Username`, **Attribute Path** = `ns:userName`
- **Schema Attribute** = `email`, **Attribute Path** = `ns:userEmail`
- **Schema Attribute** = `firstName`, **Attribute Path** = `ns:firstName`

### Pass-Through Authentication XPath Namespace Mapping

Refer to [XPath Namespace Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html#xpath-namespace-mapping>) for more information.

Enter the following **Namespace Prefix** and **Namespace URI** pairs:

- **Namespace Prefix** = `soapenv`, **Namespace URI** = `http://schemas.xmlsoap.org/soap/envelope/`
- **Namespace Prefix** = `ns`, **Namespace URI** = `urn:partner.soap.sforce.com`
- **Namespace Prefix** = `xsi`, **Namespace URI** = `http://www.w3.org/2001/XMLSchema-instance`

## Multiple Independent Endpoints

Web Services allows aggregation from multiple independent endpoints. The Web Service depends upon the **Operation Type** and the **Parent Endpoint** configuration to determine whether the endpoints of type Aggregation or Get Object must be executed independently.

- When Aggregation and Get Object endpoints need to aggregate attributes from multiple endpoints in a chained manner, the administrator must configure the parent endpoint name in every child endpoint. There has to be a dependency between the first and subsequent endpoints. The parent endpoint must be explicitly configured using the **Parent Endpoint** configuration tab.
- If multiple child endpoints are configured for any given endpoint, then the sequence of execution of child endpoints is determined by the sequence in which they have been configured in the application. For example, if account aggregation requires attributes from four different endpoints (EP1, EP2, EP3, and EP4), then:

  1. EP1 aggregates userId and primary email.
  2. EP2 aggregates personal information using userId.
  3. EP3 aggregates skill ID information using primary email.
  4. EP4 aggregates skill name using skill ID from EP3.

  Where EP = Endpoint and RO = Resource Object/Account object.

### Configuring Multiple Independent Endpoints for Aggregation

- For a target system where accounts are aggregated from multiple endpoints and there is no relationship between such endpoints, you can configure Web Services to aggregate information from independent endpoints.
- Each endpoint can be configured independently using the same **Operation Type**. No parent endpoint configuration is required.
- Every independent endpoint can have a paging of its own, if applicable.
- Every endpoint collects resource objects from the configured Web Service. Upon completion of collecting all information, the next independent endpoint is triggered for collecting resource objects. For example, if there are two endpoints EP1 and EP2, then EP1 aggregates accounts from a certain geographic location and EP2 aggregates from another.

  | Endpoint Name | Child Endpoint(s) | Returns |  |
  | --- | --- | --- | --- |
  | EP1 | EP2, EP3, EP5 | RO(1, RO(2), RO(3,4), RO(5)), RO(6,7), RO(8) | Independent |
  | EP2 | \- | RO(2) | Child of EP1 |
  | EP3 | EP4 | RO(3,4) | Child of EP1 |
  | EP4 |  | RO(4) | Child of EP3 |
  | EP5 |  | RO(5) | Child of EP1 |
  | EP6 | EP7 | RO(6,7), RO(8) | Independent |
  | EP7 |  | RO(7) | Child of EP6 |
  | EP8 |  | RO(8) | Independent |

> [!NOTE]
>
> **Screenshot**
>
> [![Multiple Independent Endpoints](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/multiple_independent_endpoints.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/multiple_independent_endpoints.png>)

> [!NOTE]
>
> The **Parent Endpoint** configuration tab displays for existing Web Services SaaS sources. However, any changes to the parent configuration have no effect on such applications and the operations behave per the previous endpoint chaining rules: the first endpoint of the specific operation type is the parent and subsequent endpoints of the same operation type are its child endpoints.

### Parent Endpoint

The Parent Endpoint tab displays for aggregation operations. Refer to [Aggregation](<https://documentation.sailpoint.com/connectors/web_services/saas/help/operations_reference.html#aggregation>) for more information.

> [!NOTE]
>
> **Screenshot**
>
> [![Parent Endpoint](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/parent_endpoint.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/parent_endpoint.png>)

1. Select the **Parent Endpoint** from the dropdown list.
2. Select **Save**.

## Enabling Single API Calls

The Web Services connector supports sending data for multiple users in a single API call. If the managed system supports sending data for multiple users in a single call, the single API call can be enabled or configured by adding the `evalPattern`.

Add the following evaluation pattern function to the **Body** or **URL** to send attributes in the request:

```text
evalPattern(pattern,delimiter,count)
```

The following table describes the terminology used in the above evaluation pattern (`evalPattern`) function, which is used to specify the repeated pattern of attributes data to be resolved:

| Attributes | Description |
| --- | --- |
| `pattern` | Repeated pattern for a set of users in the request. |
| `delimiter` | Delimiter for the repeated patterns. |
| `count` | (Optional) Specifies the number of users' data to be sent with the request endpoint. The default value is 10 for query parameters and 50 for Body parameters. |

For example, consider the Get Users data API:

- **Required URL**:

  ```text
  http://Hostname:8080/identityiq/scim/v2/Users?filter=userName eq "spadmin" or userName eq "abhijit" or userName eq "wadekar" or userName eq "imran" or userName eq "test"
  ```
- **Modified URL** - The following modified URL used to get users data API has an `evalPattern` placeholder which is replaced with resolved information. The placeholder string is replaced by five repeated patterns of `userName` placeholders and a separator.

  ```text
  http://Hostname:8080/identityiq/scim/v2/Users?filter=evalPattern("userName eq $response.userName$"," or ",5)
  ```

> [!NOTE]
>
> **Notes**
>
> - This functionality is not applicable for the first aggregation endpoint.
> - If the API supports sending limited user data, then it must be specified in `evalPattern(count)` to avoid failures.

Merging of resources is done based on the ID for each endpoint which are provided as placeholders in the pattern. For example:

```text
$response.userName$ (userName)
```

Refer to [Customizers](<https://documentation.sailpoint.com/connectors/web_services/saas/help/customizers.html>) and [Dataset Management](<https://documentation.sailpoint.com/connectors/web_services/saas/help/datasets.html>) for more information on other SaaS-only configuration capabilities.

# Connecting SailPoint and Web Services SaaS

When you add the source in SailPoint, choose whether to add it using **Standard Setup** or the **Connectivity Agent**:

- **Standard Setup**: Provide the basic configuration to create the source, then proceed with the remaining source setup.
- **Connectivity Agent**: Set up your source using an AI-based agent that provides contextual recommendations for complex configurations. Refer to [Connectivity Agent Setup](<https://documentation.sailpoint.com/connectors/web_services/saas/help/connectivity_agent_setup.html>) for more information.

## Standard Setup

To connect SailPoint with Web Services, perform the following tasks:

## Adding the Source in SailPoint

To connect to SailPoint, perform the following steps. Once the connection is made, you can configure it to meet your company's needs.

> [!IMPORTANT]
>
> By default, the provisioning feature is **disabled**, and the connector only supports read-only operations. To support provisioning operations, you must manually enable the feature in the source configuration.

**To configure a new source:**

1. Sign in to SailPoint.
2. Go to **Admin \> Connections \> Sources**.
3. Select **Create New**.
4. Search for the connector by entering the name in the search box, and then select **Configure**.
5. In the **Source Name** field, enter a unique and descriptive name for your source. Source names cannot exceed 128 characters.
6. In the **Description** field, provide additional details about the source to help distinguish it from similar sources. This field allows a maximum of 2,000 characters.
7. In the **Source Owner** field, begin typing the name of an owner. Matches appear after you type two or more letters. For more information, refer to [Assigning a Source Owner](<https://documentation.sailpoint.com/saas/help/sources/index.html#assigning-a-source-owner>).
8. (Optional) Select a governance group to grant its members [source](<https://documentation.sailpoint.com/saas/help/common/users/user_levels.html#source-sub-admin-user-level>) or [role](<https://documentation.sailpoint.com/saas/help/common/users/user_levels.html#role-sub-admin-user-level>) sub-admin level oversight of the source and its access. For more information, refer to [Creating and Managing Governance Groups](<https://documentation.sailpoint.com/saas/help/common/users/governance_groups.html>).
9. If this source represents a primary system containing your organization's personnel records, select the **Authoritative Source** checkbox. For more information, refer to [Creating Identity Profiles](<https://documentation.sailpoint.com/saas/help/setup/identity_profiles.html>).
10. Select **Continue**. The source is created, and you are navigated to the **Source Setup \> Base Configuration** page. Continue to configure your connected source there.

## Base Configuration

Provide the base configuration parameters. Information you entered in the Create New Source dialog is automatically entered into the fields in the Base Configuration page. You can edit this information if necessary.

1. Enter a unique name and description for the source.
2. In the **Source Owner** dropdown list, select the identity that owns this source.

   - To find a source owner, begin entering their name.
3. (Optional) If enabled for your organization, select the **Use a Credential Provider** checkbox to manage the source's authentication using a credential provider.

   > **Note**
   >
   > To add a credential provider, go to **Admin \> Connections \> Credential Providers**. For more information about credential providers, refer to [Credential Providers](<https://documentation.sailpoint.com/connectors/help/credential_providers.html>).
4. Configure the authentication to allow SailPoint to connect to the source. Refer to [Connection Settings](<#connection-settings>) for more information.
5. (Optional) In the **Governance Group for Source Management** dropdown list, select a governance group to associate with this source. For more information about governance groups, refer to [Associating Governance Groups with a Source](<https://documentation.sailpoint.com/saas/help/common/users/governance_groups.html#associating-a-governance-group-with-a-source>).
6. (Optional) Choose whether to enable or disable provisioning for the source. Provisioning is disabled by default.

   - **Enable Provisioning** - Set the toggle to **Enabled** to allow the source to create, update, and deactivate accounts in the connected source system.
   - **Disable Provisioning** - Set the toggle to **Disabled** to disable provisioning for the source. Disabling provisioning will prevent the creation, updating, or deactivating of accounts on this source.
7. Select **Save**.

## Connection Settings

The following information is required for SailPoint to connect and interact with Web Services SaaS.

1. Select **Connection Settings** from the menu.
2. Select an **Authentication Type**.

Select the authentication type your source uses. You can enter the supporting authentication information in the fields provided below your selection. The supporting fields that display change depending on your selected authentication type.

The SailPoint Web Services SaaS connector supports the following authentication types:

- [Basic Authentication](<#basic-authentication>)
- [API Token](<#api-token>)
- [OAuth 2.0](<#oauth-20>)
- [Custom Authentication](<#custom-authentication>)

### Basic Authentication

> [!NOTE]
>
> **Screenshot**
>
> [![Basic Authentication](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/basic_authentication.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/basic_authentication.png>)

1. From the **Authentication Type** dropdown list, select **Basic Authentication**.
2. In the **Base URL** field, enter the base URL to connect to the target managed system. For example:

   `https://api.testurl.com`
3. Enter the **Username** and **Password** for the account with the required permissions to execute Web Services.
4. Configure the [Aggregation Settings](<https://documentation.sailpoint.com/connectors/web_services/saas/help/source_settings.html#aggregation-settings>) and [Common Configuration](<https://documentation.sailpoint.com/connectors/web_services/saas/help/source_settings.html#common-configuration>) settings that apply, then select **Save**.

### API Token

The connector can authenticate with the source using an API token. The API token you provide is saved to the `accesstoken` attribute in the application configuration. API tokens are given in the following format:

```text
token_type API_token
```

For example:

```text
Bearer ********
```

> [!NOTE]
>
> If the token type is not provided, then the connector automatically uses `Bearer`.

#### API Token Placeholders

You can reference a saved API token using a placeholder. The token placeholder can be provided as a variable across all endpoints for request components such as:

- Request URL
- HTTP Headers
- Request Body

The following is an example of an API token placeholder:

```text
$application.accesstoken$
```

You can define and use multiple API token placeholders if your configuration requires it. Refer to [Custom Authentication](<#custom-authentication>) for more information on API token placeholders.

> [!NOTE]
>
> **Screenshot**
>
> [![API Token](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/api_token.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/api_token.png>)

1. Select **API Token** as the **Authentication Type**.
2. Enter the **Base URL** to connect to the managed system. For example:

   `https://api.testurl.com`
3. Enter the **API Token** specific to the managed system.
4. Configure the [Aggregation Settings](<https://documentation.sailpoint.com/connectors/web_services/saas/help/source_settings.html#aggregation-settings>) and [Common Configuration](<https://documentation.sailpoint.com/connectors/web_services/saas/help/source_settings.html#common-configuration>) settings that apply, then select **Save**.

### OAuth 2.0

For all the grant types that you can select, the following fields are common configuration. Other grant type details are described in the following subsections.

> [!NOTE]
>
> **Screenshot**
>
> [![OAuth 2.0](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/oauth_2.0.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/oauth_2.0.png>)

1. Select **OAuth 2.0** as the **Authentication Type**.
2. In the **Base URL** field, enter the base URL to connect to the target managed system. For example:

   `https://api.testurl.com`
3. Enter the **Token URL**. The format is:

   `https://{your domain}/token`

   Web Services supports the replacement of attributes in the OAuth 2.0 token URL. For example, if you want to prepare a token URL with sensitive information such as **client\_secret**, `$application.client_secret$` can be used. The corresponding value is determined from the replaced location in the token URL.
4. For **OAuth Headers**, set up the custom headers as part of the access token. Web Services adheres to the generalized specifications of the OAuth 2.0 grant types. However, for some managed target systems, custom headers may be required to be part of the access token generation request. You can add the custom headers as an attribute.

   > **Note**
   >
   > The Content-Type value can only be **application/x-www-form-urlencoded** when Authentication Type is selected as OAuth 2.0. If the managed system expects a Content-Type other than **application/x-www-form-urlencoded**, use Custom Authentication instead of OAuth 2.0.
5. In **OAuth Headers to Exclude**, enter the headers that you want to exclude. By default, an Authorization BASIC header with a Base64-encoded client ID and client secret is part of the access token generation request. Some managed target systems do not support this header. If there is no Authorization BASIC header required for such managed target systems, it can be excluded from the request.
6. For **OAuth Request Parameters**, set up the custom parameters for an access token. For some managed target systems, custom request parameters may be required to be part of the access token generation request. You can add the custom request parameter as an attribute.
7. For **OAuth Body Attributes to Exclude**, enter the attributes that you want to exclude. To remove any of the standard request parameters that are not supported by managed target systems' access token generation requests, configure the request parameters to exclude from the access token request.
8. Select a **Grant Type** and complete its configuration:

   - [Password Grant Type](<#password-grant-type>)
   - [Client Credentials](<#client-credentials>)
   - [Refresh Token](<#refresh-token>)
   - [JWT Bearer Token](<#jwt-bearer-token>)
   - [SAML Bearer Assertion](<#saml-bearer-assertion>)
9. Configure the [Aggregation Settings](<https://documentation.sailpoint.com/connectors/web_services/saas/help/source_settings.html#aggregation-settings>) and [Common Configuration](<https://documentation.sailpoint.com/connectors/web_services/saas/help/source_settings.html#common-configuration>) settings that apply, then select **Save**.

#### Password Grant Type

For the **Password** Grant Type:

> [!NOTE]
>
> **Screenshot**
>
> [![Password Grant Type](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/password_grant_type.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/password_grant_type.png>)

1. Select **Password** as the **Grant Type**.
2. Enter the **Username** and **Password** to authorize with the source.

#### Client Credentials

For the **Client Credentials** Grant Type:

> [!NOTE]
>
> **Screenshot**
>
> [![Client Credentials](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/client_credentials.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/client_credentials.png>)

1. Select **Client Credentials** as the **Grant Type**.
2. Enter the **Client ID** and its associated **Client Secret**. These are the client identification and secret for OAuth 2.0 authentication.

#### Refresh Token

For the **Refresh Token** Grant Type:

> [!NOTE]
>
> **Screenshot**
>
> [![Refresh Token](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/refresh_token.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/refresh_token.png>)

1. Select **Refresh Token** as the **Grant Type**.
2. Enter the **Client ID** and the associated **Client Secret** for OAuth 2.0 authentication.
3. Enter the **Refresh Token** used to generate the access token. Web Services supports OAuth 2.0 Refresh Tokens for the managed target system. The refresh tokens either don't expire or come with a long validity period.

#### JWT Bearer Token

For the **JWT Bearer Token** Grant Type:

> [!NOTE]
>
> **Screenshot**
>
> [![JWT Bearer Token](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/jwt_bearer_token.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/jwt_bearer_token.png>)

1. Select **JWT Bearer Token** as the **Grant Type**.
2. Enter the **Private Key** and **Private Key Password** to be used for JWT authentication.
3. Enter the **Client ID** and the associated **Client Secret** for OAuth 2.0 authentication.
4. In **JWT Header**, enter the following:

   - **Key** - The Key is the algorithm that is used for signing the JWT assertion. It must be the same algorithm that you use for generating the private key. For example, you can use `alg`.
   - **Value** - The Value is the JWT headers key. For example, you can use the value `RS256`. If required, additional header attributes can be provided in the key-value pair mentioned above.
5. In **JWT Payload**, enter the following:

   - **Key** - The Payload Key enables you to include information on the JWT Claim. For JWT authentication, it is mandatory to have the payload key for a successful test connection and other operations. The mandatory attributes are:

     - `aud` (Audience)
     - `exp` (Expiry of the JWT assertion)
     - `iss` (Issuer)
     - `sub` (Subject)

     If required, additional payload attributes can be provided in this key-value pair based on the target system.
   - **Value** - The value of the Payload Key.

#### SAML Bearer Assertion

For the **SAML Bearer Assertion** Grant Type:

> [!NOTE]
>
> **Screenshot**
>
> [![SAML Bearer Assertion](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/saml_bearer_assertion.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/saml_bearer_assertion.png>)

1. Select **SAML Bearer Assertion** as the **Grant Type**.
2. Enter the **Client ID** and the associated **Client Secret** for OAuth 2.0 authentication.
3. Enter the **SAML Assertion URL** for generating a SAML Assertion. The SAML Assertion URL supports placeholders for replacement of the source attribute dynamically. For example, if a SAML Assertion URL is required to be prepared with some sensitive information such as a password, use `$application.saml_password$`. The corresponding value is determined from the source and replaced at the appropriate location in the SAML Assertion URL.
4. Enter the **SAML Request Body** that generates a SAML Assertion. SailPoint recommends that you use `$application.saml_username$` and `$application.saml_password$` placeholders in the request body to prevent exposing any sensitive data.
5. Enter the **Username** and **Password** for the service account with required permissions to execute Web Services.
6. In **SAML Headers**, enter the **Key** and respective **Value**. These are used for SAML assertion generation.
7. Enter any **SAML Headers to Exclude** which apply. By default, an Authorization BASIC header with a Base64-encoded resource username and resource password is part of the SAML Assertion generation request. Some managed target systems do not support such a header. If there is no Authorization BASIC header requirement for such target systems, it can be excluded from the request.

### Custom Authentication

When you select **Custom Authentication** as the **Authentication Type**, Web Services aggregates the authentication details for all other endpoints.

In custom authentication, the Web Services source doesn't authenticate requests and doesn't add any authorization to the HTTP header. To accomplish this, the REST application requires a new token to authenticate the request from the Authentication Server.

> [!IMPORTANT]
>
> If an endpoint does not require authentication at all, you only need to select **Custom Authentication**. Continue to the following steps to set up custom authentication.

> [!NOTE]
>
> **Screenshot**
>
> [![Custom Authentication](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/custom_authentication.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/custom_authentication.png>)

1. From the **Authentication Type** dropdown list, select **Custom Authentication**.
2. In the **Base URL** field, enter the base URL to connect to the target managed system. For example:

   `https://api.testurl.com`
3. (Optional) Several optional fields display which you can configure as your authentication configuration requires:

   - Username
   - Password
   - API Token
   - Resource Owner Username
   - Resource Owner Password
   - Private Key
   - Private Key Password
   - Client ID
   - Client Secret
   - Refresh Token
4. Select **Save**.
5. Go to **HTTP Operations**, and select **Add Operation**. Set the **Operation Type** to **Custom Authentication**. Refer to [HTTP Operations](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html>) for more information about using the HTTP Operations fields.
6. Configure the following for endpoints:

   - **Authentication URL** - From the endpoint details page, enter the full URL in the **Authentication URL** field.

     > **Note**
     >
     > Ensure that you enter the full URL in this field, unlike the other endpoints where this field takes in the context URL.
   - **Header and Body**:

     1. Configure the Header and Body with the required fields for the token generation.
     2. Keys for sensitive attributes updated in the Header and Body must be appended in the encrypted list in the application.

        > **Caution**
        >
        > Don't configure sensitive attributes for the Header and Body through the configuration UI. They should be added using the SailPoint Update Source Partial REST API. Refer to [SailPoint REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>) for more information.

        When you add sensitive attributes to the header, ensure that the attributes are added with the suffix `_CA`. For example, to use a password in the request, add `password_CA`.

        > **Note**
        >
        > If the attributes are not suffixed with `_CA`, the Web Services source might display unusual behavior.

        For example, if the attribute updated is a password, then it must be added to the header as follows.

        Before updating the encrypted list:

        ```json
        {"encrypted":"accesstoken,password,refresh_token,oauth_token_info,client_secret,private_key,private_key_password,clientCertificate,clientKeySpec,resourceOwnerPassword,custom_auth_token_info"}
        ```

        After updating the encrypted list:

        ```json
        {"encrypted":"accesstoken,password,refresh_token,oauth_token_info,client_secret,private_key,private_key_password,clientCertificate,clientKeySpec,resourceOwnerPassword,custom_auth_token_info,password_CA"}
        ```

        After the attributes are added, their values can be used as placeholders in the Header and Body. For example:

        ```text
        $application.password_CA$
        ```

        - Use the `password_CA` attribute key with a value such as `xyz123`.
        - Add the `password_CA` key to the existing encrypted attribute (comma-separated) using the SailPoint REST API.
        - Use the `encrypted` attribute key and append `,password_CA` to the existing value.
   - **Response Mapping** - Configure **Response Attribute Mapping** to obtain the access details from the response. Response mapping is the same as the other endpoints; the key is added under **Response Attribute** and its respective path must be added under **Attribute Path**.

     > **Note**
     >
     > The value under **Response Attribute** must not be present in the schema. After response parsing, the value is stored in key-value format as follows:
     >
     > ```json
     > {"accesstoken":"access_token"}
     > ```
7. The token value generated after executing the **Custom Authentication** endpoint can be utilized in all other endpoints using placeholders as follows:

   ```text
   "$application.<your key>$"
   ```

   For example:

   ```text
   "$application.accesstoken$"
   ```

   If the token type is for a **Bearer** instance, then it can be used as follows:

   ```text
   "<your token type> $application.<your key>$"
   ```

   For example:

   ```text
   "Bearer $application.accesstoken$"
   ```
8. Configure the [Aggregation Settings](<https://documentation.sailpoint.com/connectors/web_services/saas/help/source_settings.html#aggregation-settings>) and [Common Configuration](<https://documentation.sailpoint.com/connectors/web_services/saas/help/source_settings.html#common-configuration>) settings that apply, then select **Save**.

## Review and Test

Perform a test to confirm the connection to SailPoint.

1. Go to **Review and Test**.
2. Confirm that the entries in each field are correct.

   If you note any mistakes, return to the section and make corrections.
3. Select **Test Connection**.

## SailPoint Application Onboarding

SailPoint application onboarding enables you to easily onboard new applications and create sources following the successful onboarding of a discovery source. To use this feature, continue to **Discovered Applications** in the SailPoint user interface.

For more information, refer to [Application Onboarding](<https://documentation.sailpoint.com/saas/help/ai/app_onboarding/index.html>) in the SailPoint SaaS documentation.

# Connectivity Agent Setup

Select **Connectivity Agent \> Enable and Continue**.

> [!NOTE]
>
> By selecting **Enable and Continue**, you agree to [SailPoint's AI Terms](<https://www.sailpoint.com/legal/product-specific-terms#ai>).

> [!NOTE]
>
> **Screenshot**
>
> [![Connectivity Agent](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/connectivity_agent.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/connectivity_agent.png>)

> [!NOTE]
>
> Select **Learn more** for more information about the following:
>
> - **Recommendations** - Suggested source configuration settings in SailPoint, generated by the Connectivity Agent using available documentation. Depending on the target application, these can include endpoints, operations authentication types, and aggregation types and related settings.
> - **Confidence Levels** - The strength of the documentation backing a recommendation:
>
>   - **High** - The recommendation is based on the target application's official documentation.
>   - **Low** - The recommendation is based on third-party documentation rather than the target application's official documentation.

> [!IMPORTANT]
>
> - **Errors**
>
>   - If an error occurs while generating suggestions, select **Retry**.
>   - If the error persists, select **Switch to Standard Setup** when the Connectivity Agent displays the option.
>   - Select the **gear** icon in the top-right corner to switch to Standard Setup.
> - Only REST-based APIs are supported.

> [!WARNING]
>
> Switching to Standard Setup is permanent. You cannot return to Connectivity Agent setup, even if you go to the Sources page, select your source, and attempt to resume your configuration.

## Source Setup

1. On the **Source Setup** tab, enter the source name in the **Target System Name** field.

   > **Note**
   >
   > The name must be between 2 and 50 characters.
2. In the Connectivity Agent panel, select **Save and Continue**. Wait while the Connectivity Agent generates recommendations.

   > **Note**
   >
   > To generate new recommendations, edit the **Target System Name** and select **Refresh**.
3. Depending on the results, perform one of the following actions:

   - If a match is found, select the target system.
   - If multiple target systems are listed, select one from the list.
   - If no results are found, enter a different name, select **Refresh**, and select the target system. If the error persists, select Switch to Standard Setup.
4. Select **Save and Continue**. Wait while the Connectivity Agent locates the account objects associated with the target system.
5. Depending on the results, perform one of the following actions:

   - If an account object is found, select the account object.
   - If multiple account objects are listed, select one from the list.
6. Select **Save and Continue**. Wait while the Connectivity Agent generates the connection recommendations. You are navigated to the Connections tab.

## Connections

1. On the **Connections** tab, review the authentication types listed in the Connectivity Agent panel. The available authentication types vary based on the target system you selected.
2. Select an authentication type, and select **Save and Continue**. Wait while the Connectivity Agent configures the Test Connection endpoint.

   > **Important**
   >
   > The Connectivity Agent does not support custom authentication.

   - Once the **Test Connection** endpoint is configured, enter the authorization credentials to connect to the source.
   - If you want to test the connection, select **Test Connection**. If the test connection fails, select **View Test Connection Configuration** and configure the test connection endpoint.
   - If you want to configure authentication later, leave the fields blank.
3. Select **Save and Continue**. Wait while the Connectivity Agent generates recommendations for the account aggregation. You are navigated to the HTTP Operations tab.

## HTTP Operations

Review and edit how the source accounts and its child endpoints are configured and how account entitlement information is collected.

### Account Aggregation

Overview:

1. **Account**:

   1. Select the **Edit** icon for each account aggregation endpoint to review the configuration and update it if required. Refer to [HTTP Operations](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html>) for more information.
   2. You can manage the [Account Schema](<#account-schema>) and [Preview](<#preview>) the account aggregation configuration.
2. Select **Save and Continue**. Wait while the Connectivity Agent creates the child endpoints.
3. **Child Endpoints** (Optional):

   1. Select one or more child endpoints and select **Save and Continue**. Wait while the Connectivity Agent configures the child endpoints. Select **Skip \> Save and Continue** to skip the child endpoint configuration and proceed with the next steps.
   2. Select the **Edit** icon for each child endpoint (if configured) to review the configuration and update it if required. Refer to [HTTP Operations](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html>) for more information.
   3. You can manage the [Account Schema](<#account-schema>) and [Preview](<#preview>) the account aggregation configuration.

   > **Note**
   >
   > If an error occurs while generating suggestions, select **Retry**. If the error persists, select **Save and Continue**. You are navigated to the Entitlement Aggregation tab.

### Account Schema

1. Select the **Account Schema** tab.
2. Review and update the schema through the following actions:

   - To add a new attribute, select **Add New Attribute** and fill out all required fields. Select **Save** to save your changes and **Cancel** to discard your changes.

     > **Note**
     >
     > Account attributes cannot exceed 128 characters.
   - To edit a source's Account Name and Account ID attributes, select **Edit Schema**. Under **Account ID** and **Account Name**, choose the attributes that should be used to provide those values and select **Update**.
   - To edit an attribute, select **Actions \> Edit**. Select **Update** to save your changes and **Cancel** to discard your changes.
   - To delete an attribute, select **Actions \> Delete**. You can also select the checkbox beside attributes in this list and select **Delete Attributes**.

### Preview

1. Select the **Preview** tab.
2. Select **Preview** to generate and review the account aggregation configuration.

   - If an error occurs, review the error details and select **Learn More** to access the documentation and resolve the issue. After resolving the issue, select **Preview** again to view the updated configuration.
   - While the preview is generating, you can edit the **Overview** and **Account Schema** pages and select **Preview** again to view the updated configuration.
3. Select **Save and Continue**. Wait while the Connectivity Agent performs the account's preview. You are navigated to the Entitlement Aggregation tab.

### Entitlement Aggregation

> [!NOTE]
>
> If an error occurs while generating recommendations, select **Retry**. To skip and proceed, select **Save and Continue**.

Overview:

**Entitlement Aggregations**: Select the **Edit** icon for each entitlement aggregation endpoint to review the configuration and update it if required. Refer to [HTTP Operations](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html>) for more information.

**Entitlement Schema**:

1. Select the **Entitlement Schema** tab.
2. Review and update the schema through the following actions:

   - To add a new attribute, select **Add New Attribute** and fill out all required fields. Select **Save** to save your changes and **Cancel** to discard your changes.

     > **Note**
     >
     > Entitlement attributes cannot exceed 128 characters.
   - To edit a source's Entitlement ID and Entitlement Name attributes, select **Edit Schema**. Under **Entitlement ID** and **Entitlement Name**, choose the attributes that should be used to provide those values and select **Update**.
   - To edit an attribute, select **Actions \> Edit**. Select **Update** to save your changes and **Cancel** to discard your changes.
   - To delete an attribute, select **Actions \> Delete**. You can also select the checkbox beside attributes in this list and select **Delete Attributes**.

**Preview**:

1. Select the **Preview** tab.
2. Select **Preview** to generate and review the entitlement aggregation configuration.

   - If an error occurs, review the error details and select **Learn More** to access the documentation and resolve the issue. After resolving the issue, select **Preview** again to view the updated configuration.
   - While the preview is generating, you can edit the **Overview** and **Entitlement Schema** pages and select **Preview** again to view the updated configuration.
3. Select **Save and Continue**. Wait while the Connectivity Agent performs the entitlement's preview.

   > **Note**
   >
   > If an error occurs while generating recommendations, select **Retry**. To skip and proceed, select **Save and Continue**.
4. Your aggregation configuration is now complete. Perform one of the following actions:

   - **Complete the Source Setup** and review the final configuration.
   - **Enable and Configure Provisioning** to configure provisioning operations.
5. Select **Save and Continue**. Wait while the Connectivity Agent performs the action. You are navigated to the respective tab.

## Provisioning (Optional)

1. The Connectivity Agent discovers whether the application supports write capabilities and populates the matching provisioning operations based on its search results.

   > **Note**
   >
   > If an error occurs while generating recommendations, select **Retry**. To skip and proceed, select **Save and Continue**.
2. Select one, multiple, or all provisioning operations that you want your source to support.

   > **Note**
   >
   > To configure provisioning operations later in Standard Setup, select **Skip** and select **Save and Continue**. You are navigated to the Review tab.
3. Select **Save and Continue**. Wait while the Connectivity Agent configures the provisioning endpoints for each operation.
4. On the **Provisioning** tab, select the **Edit** icon for each endpoint to review the configuration and update it if required. Refer to [HTTP Operations](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html>) for more information.
5. Select **Save and Continue**. Wait while the Connectivity Agent completes the provisioning configuration. You are navigated to the Review tab.

## Review

1. On the **Review** tab, review the source configuration details you configured during each step:

   - Source Setup
   - Connection Settings
   - HTTP Operations
   - Provisioning
2. Select **Finish**.

> [!NOTE]
>
> Any settings or operations you skipped during the setup process appear empty or remain hidden.

After a successful configuration, the system creates your source and prompts you to run an aggregation.

- If you want to aggregate now, select **Aggregate**. The system aggregates the account and entitlements and returns you to the Sources page.

  - Go to Source, and continue with additional configuration if required.
  - To see the latest account aggregation history, go to **Source \> Account Management \> Account Aggregation**.
  - To see the list of aggregated source accounts, go to **Source \> Account Management \> Accounts**.
  - To see the latest entitlement aggregation history, go to **Source \> Entitlement Management \> Entitlements Aggregation**.
  - To see the list of aggregated entitlements, go to **Source \> Account Management \> Entitlements**.
- If you want to aggregate later, select **Cancel**. This returns you to the Sources page. Your new source is listed, but contains no accounts or aggregation history yet.

# Customizers

You can customize the Web Services SaaS connector using cloud-based connector customizers. By using a customizer, you can change a connector's input before the connector ingests the data, or you can change the connector's output before the output is sent to SailPoint.

## Prerequisites

- To use the customizers, SailPoint CLI is required. To set it up, refer to [CLI](<https://developer.sailpoint.com/idn/tools/cli/>) in the SailPoint Developer Community.
- To build and upload the SaaS connector customizer, refer to [Building and Uploading to Identity Security Cloud](<https://developer.sailpoint.com/idn/tools/cli/>) in the SailPoint Developer Community.
- To find the commands available to implement in a SaaS connector customizer, refer to [Customizer Commands](<https://developer.sailpoint.com/docs/connectivity/saas-connectivity/customizers/commands>) in the SailPoint Developer Community.

> [!NOTE]
>
> **Example 1**
>
> If you want to change the input attributes before account creation, you can use the `beforeStdAccountCreate` method. Consider a use case where an attribute that is not present in the schema (`userType`) needs to be added before the account creation to determine which account type you want to create. Refer to the following template:
>
> ```typescript
> // Get connector source config
> const config = await readConfig()
>
> return createConnectorCustomizer()
>
>     .beforeStdAccountCreate(async (context: Context, input: StdAccountCreateInput) => {
>         logger.info(`Running before account, for account ${input.identity}`)
>         input.attributes.userType = 'member';
>         return input
>     })
> ```

> [!NOTE]
>
> **Example 2**
>
> If you want to change the output attributes after account read, you can use the `afterStdAccountRead` method. Let's consider a use case where an attribute that is not present in the schema (active), needs to be added after the account aggregation has been performed for determining whether the user is active or not. Refer to the following template:
>
> ```typescript
> // Get connector source config
> const config = await readConfig()
>
> return createConnectorCustomizer()
>
>     .afterStdAccountRead(async (context: Context, output: StdAccountReadOutput) => {
>         logger.info(`Running after account read for account ${output.identity}`)
>         output.attributes.isActive = true;
>         return output
>     })
> ```

> [!NOTE]
>
> **Example 3**
>
> If you want to change the input attributes before account aggregation, you can use the `beforeStdAccountAggregation` method. Consider a use case where you want to determine the number of accounts that were aggregated the last time aggregation was performed. Refer to the following template:
>
> ```typescript
> // Get connector source config
> const config = await readConfig()
>
> return createConnectorCustomizer()
>
>     .beforeStdAccountList(async (context: Context, input: StdAccountListInput) => {
>         logger.info(`Running before account list for account. State: ${input.state.last_aggregation_count}`)
>         return input
>     })
> ```

> [!NOTE]
>
> **Example 4**
>
> If you want to make changes in one or more operations as mentioned in the above templates, you can club them together. Refer to the following template:
>
> ```typescript
> // Get connector source config
> const config = await readConfig()
>
> return createConnectorCustomizer()
>
>     .beforeStdAccountList(async (context: Context, input: StdAccountListInput) => {
>         logger.info(`Running before account list for account. State: ${input.state.last_aggregation_count}`)
>         return input
>     })
>     .afterStdAccountRead(async (context: Context, output: StdAccountReadOutput) => {
>         logger.info(`Running after account read for account ${output.identity}`)
>         output.attributes.isActive = true;
>         return output
>     })
>     .beforeStdAccountCreate(async (context: Context, input: StdAccountCreateInput) => {
>         logger.info(`Running before account, for account ${input.identity}`)
>         input.attributes.userType = 'member';
>         return input
>     })
> ```

## Endpoint Customization

You can customize endpoints used by the Web Services SaaS connector. The endpoint customizations can take place before or after HTTP operations that affect a given endpoint, such as Test Connection or Aggregation. Customizations that the connector can make to an endpoint include, but aren't limited to, changes to its physical address or its behavior.

- [Configure Endpoint Customization Before Operations](<#configure-endpoint-customization-before-operations>)
- [Configure Endpoint Customization After Operations](<#configure-endpoint-customization-after-operations>)

### Objects Used in Endpoint Customization

| Object Name | Object Reference |
| --- | --- |
| Request Body | `input._requestConfig.body` |
| Request URL | `input._requestConfig.url` |
| Request Headers | `input._requestConfig.headers` |
| Request method | `input._requestConfig.httpMethodType` |
| Page Offset | `input._pagingProcessor._pageInitialOffset` |
| Page Size | `input._pagingProcessor._pageSize` |
| Application Attributes | `input.applicationAttributes` |
| Response | `input.rawResponse.response` |
| Response Code | `input.rawResponse.status` |

### Configure Endpoint Customization Before Operations

Configure the connector to make a customization to an existing endpoint before operations. The connector looks for the `isBeforeCustomizer` parameter in the endpoint. The presence of this parameter in the endpoint signals to the connector that there is a customization process that needs to take place before the operation.

To add an endpoint customization before the operation, ensure that the following prerequisites have been completed prior to running the operation:

- Add a new parameter to the endpoint using the SailPoint REST API to indicate a customization requirement:

  ```text
  "isBeforeCustomizer":true
  ```

  > **Note**
  >
  > Refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>) in the SailPoint Developer Community for more information on SailPoint's REST APIs.
- Create a customizer project that actually executes the required endpoint customization. Refer to [Customizers - Get started](<https://developer.sailpoint.com/docs/connectivity/saas-connectivity/customizers/getting-started/>) in the SailPoint Developer documentation for more information about creating a customizer project. Add the `customizedOperation` method with two parameters:

  - The `uniqueNameForEndPoint` followed by a `:before` suffix (for example, `Test Connection:before`) to execute the customizer project before the endpoint
  - The handler to run

#### Objects Used in Before Operation Customizations

| Object | Description |
| --- | --- |
| `application` | The application whose data file is being processed. |
| `requestEndPoint` | Current request information. It contains the header, body, context URL, method type, response attribute map, and successful response code. |

#### Examples

The following are possible example configurations for before operation configurations.

> [!NOTE]
>
> **Before Operation Customization Example \#1**
>
> In the following example, SailPoint is executing an additional API to add an access token to the headers of the Test Connection endpoint.
>
> ```typescript
> export const connectorCustomizer = async () => {
>     // Get connector source config
>     const config = await readConfig()
>     return createConnectorCustomizer()
>         .customizedOperation('Test Connection:before', async (context: Context, input: any) => {
>             // The private key is a sensitive credential. Store it securely, not in code.
>             const privateKeyPem = `-----BEGIN RSA PRIVATE KEY-----
>                             [YOUR_ENCRYPTED_PRIVATE_KEY_CONTENT_HERE]
>                             -----END RSA PRIVATE KEY-----`
>             const decryptPrivateKey = (encryptedPem: string, password: string): string => {
>                 const decryptPrivateKeyWithPassword = (encryptedPem: string, password: string): string => {
>                     // Remove header/footer and line breaks
>                     const pem = encryptedPem
>                         .replace('-----BEGIN RSA PRIVATE KEY-----', '')
>                         .replace('-----END RSA PRIVATE KEY-----', '')
>                         .replace(/\r?\n|\r/g, '')
>                         .trim()
>                     try {
>                         const decryptedKey = crypto.createPrivateKey({
>                             key: encryptedPem,
>                             format: 'pem',
>                             passphrase: password,
>                         })
>                         return decryptedKey.export({ format: 'pem', type: 'pkcs1' }).toString()
>                     } catch (err) {
>                         throw new Error('Failed to decrypt private key: ' + err)
>                     }
>                 }
>                 return decryptPrivateKeyWithPassword(encryptedPem, password)
>             }
>
>             const generateAssertion = (decryptedKey: string): string => {
>                 const now = Math.floor(Date.now() / 1000)
>                 // Payload values are specific to your application configuration in Okta.
>                 const payload = {
>                     aud: 'https://your-okta-domain.com/oauth2/v1/token',
>                     sub: 'your-client-id',
>                     iss: 'your-client-id',
>                     jti: Math.random().toString(36).substring(2),
>                     iat: now,
>                     exp: now + 600, // 10 minutes
>                 }
>                 return jwt.sign(payload, decryptedKey, {
>                     algorithm: 'RS256',
>                     header: {
>                         typ: 'JWT',
>                         alg: 'RS256',
>                     },
>                 })
>             }
>             // The passphrase for the private key is also a secret.
>             const decryptedKey = decryptPrivateKey(privateKeyPem, 'your-private-key-passphrase')
>             const assertion = generateAssertion(decryptedKey)
>             const authenticate = async (jwtAssertion: string): Promise<string | null> => {
>                 const url = 'https://your-okta-domain.com/oauth2/v1/token'
>                 const data = new URLSearchParams({
>                     grant_type: 'client_credentials',
>                     // Scopes define the permissions your application is requesting.
>                     scope: 'okta.users.read okta.groups.read okta.schemas.manage',
>                     client_assertion_type: 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer',
>                     client_assertion: jwtAssertion,
>                 })
>                 try {
>                     const response = await axios.post(url, data.toString(), {
>                         headers: {
>                             'Content-Type': 'application/x-www-form-urlencoded',
>                         },
>                     })
>                     const accessToken = response.data.access_token
>                     return accessToken
>                 } catch (error: any) {
>                     console.error('Authentication failed:', error.message)
>                     return null
>                 }
>             }
>             const accessToken = await authenticate(assertion)
>             const headers = {
>                 Authorization: `Bearer ${accessToken}`,
>             }
>             input._requestConfig.headers = headers
>             return input
>         })
> }
> ```

> [!NOTE]
>
> **Before Operation Customization Example \#2**
>
> In this example, SailPoint is iterating through the user role received from the input, and then assigning them to the request object based on their type, array, or string.
>
> ```typescript
> export const connectorCustomizer = async () => {
>     // Get connector source config
>     const config = await readConfig()
>     return createConnectorCustomizer()
>         .customizedOperation('Add Entitlement:before', async (context: Context, input: any) => {
>             // Custom logic for the new operation
>             logger.info('Update Account:before - running ' + JSON.stringify(input._requestConfig))
>             const body: Map<string, any> = input._requestConfig.body
>             logger.info('bodyyyyy ' + JSON.stringify(input._requestConfig.body))
>             const jsonBody: string = body.get('jsonBody') as string
>             logger.info('JSON body received ' + JSON.stringify(jsonBody))
>             try {
>                 let jsonMap: any = null
>                 try {
>                     jsonMap = JSON.parse(jsonBody)
>                     logger.info('Parsed jsonBody successfully ' + JSON.stringify(jsonMap))
>                 } catch (e) {
>                     logger.error('Failed to parse jsonBody:', e)
>                     jsonMap = {}
>                 }
>                 if (jsonMap !== null) {
>                     let roleEntry: any = jsonMap['USER_ROLE']
>                     let role: string = ''
>                     if (roleEntry !== null && Array.isArray(roleEntry)) {
>                         const rolesArray: Array<any> = roleEntry
>                         if (rolesArray.length > 0) {
>                             role = rolesArray[0] as string
>                         }
>                     } else if (roleEntry !== null) {
>                         role = roleEntry as string
>                     }
>                     jsonMap['USER_ROLE'] = role
>                     const finalBody: string = JSON.stringify(jsonMap)
>                     input._requestConfig.body = finalBody
>                     logger.info('input body ' + JSON.stringify(input._requestConfig))
>                 }
>             } catch (ex) {
>                 console.error('Rule - MULE Modify Body: ' + ex)
>             }
>             return input
>         })
> }
> ```

### Configure Endpoint Customization After Operations

Configure the connector to make a customization to an existing endpoint after operations. The connector looks for the `isAfterCustomizer` parameter in the endpoint. The presence of this parameter in the endpoint signals to the connector that there is a customization process that needs to take place after the operation is completed.

To add an endpoint customization after operation completion, ensure that the following prerequisites have been completed prior to running the operation:

- Add the `isAfterCustomizer` parameter to the endpoint via the SailPoint REST API to indicate that there is a customization requirement.

  > **Note**
  >
  > Refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>) in the SailPoint Developer Community for more information on SailPoint's REST APIs.
- Create a customizer project that actually executes the required endpoint customization. Refer to [Customizers - Get started](<https://developer.sailpoint.com/docs/connectivity/saas-connectivity/customizers/getting-started/>) in the SailPoint Developer documentation for more information about creating a customizer project. Add the `customizedOperation` method with two parameters:

  - An endpoint identifier followed by an `:after` suffix to execute the customizer project before the endpoint
  - The handler to run

#### Objects Used in After Operation Customizations

| Object | Description |
| --- | --- |
| `application` | The application whose data file is being processed. |
| `requestEndPoint` | Current request information. It contains the header, body, context URL, method type, response attribute map, and successful response code. |
| `processedResponseObject` | This object is a list of map objects for accounts and groups. The map objects contain keys as identity attributes for the application schema, and the associated values are all the account and group attributes passed by the connector after parsing the respective API response. |
| `rawResponseObject` | The raw response string returned from the target system. This can be in JSON or XML format. |

#### Example

The following is a possible example for an after operation configuration.

> [!NOTE]
>
> **After Operation Customization Example**
>
> In this example, SailPoint is converting the XML object received as a raw response from the API to JSON, and then mapping the attributes to the schema.
>
> ```typescript
> export const connectorCustomizer = async () => {
>     // Get connector source config
>     const config = await readConfig()
>
>     return createConnectorCustomizer()
>         .customizedOperation('Account Aggregation:after', async (context: Context, input: any) => {
>             const xml2js = require('xml2js') // Require inside an async function
>             const parseStringPromise = xml2js.parseStringPromise
>
>             let jsonPrettyPrintString
>             let xmlJSONObj = await parseStringPromise(input.rawResponse.response, {
>                 explicitArray: false, // Avoid unnecessary arrays
>                 trim: true, // Remove whitespace
>             })
>             logger.info(`JSON parsed string ` + JSON.stringify(xmlJSONObj))
>             jsonPrettyPrintString = JSON.stringify(xmlJSONObj)
>             let response = JSON.parse(jsonPrettyPrintString)
>             logger.info('Response obj : ' + JSON.stringify(response))
>             let userListOutput = response.USER_LIST_OUTPUT || {}
>             if (!userListOutput.USER_LIST) throw new Error('USER_LIST_OUTPUT is undefined')
>             let userList = userListOutput.USER_LIST || {}
>
>             if (!userList?.USER) throw new Error('USER_LIST is undefined')
>
>             let finalList: {}[] = []
>             if (userList.USER) {
>                 userList.USER.forEach(
>                     (user: {
>                         CONTACT_INFO: any
>                         USER_STATUS: string
>                         BUSINESS_UNIT: string
>                         USER_ROLE: string
>                         USER_LOGIN: string
>                         USER_ID: string
>                     }) => {
>                         let newmap = new Map<any, any>()
>                         let contactInfo = user.CONTACT_INFO
>                         newmap.set('FIRSTNAME', contactInfo?.FIRSTNAME || 'Unknown')
>                         newmap.set('LASTNAME', contactInfo?.LASTNAME || 'Unknown')
>                         newmap.set('EMAIL', contactInfo?.EMAIL || 'Unknown')
>                         newmap.set('USER_STATUS', user.USER_STATUS || 'Unknown')
>                         newmap.set('BUSINESS_UNIT', user.BUSINESS_UNIT || 'Unknown')
>                         newmap.set('USER_ROLE', user.USER_ROLE || 'Unknown')
>                         newmap.set('USER_LOGIN', user.USER_LOGIN || 'Unknown')
>                         newmap.set('USER_ID', user.USER_ID || 'Unknown')
>                         finalList.push(newmap)
>                     }
>                 )
>             }
>             logger.info('final list: ' + JSON.stringify(finalList))
>             const returnData = { data: finalList }
>             return returnData
>         })
> }
> ```

# Dataset Management

Dataset Management lets you review the object types a source collects and control how the source aggregates those objects into SailPoint. Use Dataset Management to view and manage resource attributes, datasets and their resources, enable dataset aggregation schedules, perform manual aggregation, and view aggregation history.

> [!NOTE]
>
> Datasets are also available in SailPoint Agentic Fabric. Contact your Customer Success team and refer to [SailPoint Agentic Fabric](<https://documentation.sailpoint.com/saas/help/agentic_fabric/index.html>) for more information.

For more information, refer to [Managing Datasets and Resources](<https://documentation.sailpoint.com/saas/help/sources/datasets.html>) for datasets, resources, owner correlation, and aggregation.

## Datasets

A *dataset* is a named group of one or more related resources that the source aggregates together.

When aggregation runs for a dataset, the source collects all resources in that dataset from the managed system in one aggregation job. Activate or deactivate aggregation at the dataset level, not for individual resources.

> [!NOTE]
>
> Each resource belongs to exactly one dataset for that source. The source defines which resources belong to each dataset. You can enable aggregation and review associated resources, but you cannot create or delete datasets or move resources between them.

### Dataset Aggregation

Configure aggregation on the **Dataset Aggregations** tab for each dataset. Configure each dataset separately. During aggregation, your owner correlation rules are automatically applied to link machine identities to their human owners. For more information, refer to [Configuring Dataset Aggregations](<https://documentation.sailpoint.com/saas/help/sources/datasets.html#configuring-dataset-aggregations>).

## Resources

A resource defines an object type from the managed system. It specifies the kind of object, the attributes the source collects, and how the source identifies and displays each object. Resources form the building blocks of the data model.

In the UI, each resource appears under **Dataset Management** \> **Resources** with its schema. A resource does not run aggregation by itself. The dataset that owns the resource collects it during aggregation.

For more information, refer to [Managing Resources](<https://documentation.sailpoint.com/saas/help/sources/datasets.html#managing-resources>).

### Owner Correlation

Configure owner correlation on each resource to link aggregated objects to human owners. If you do not configure owner correlation, or if the mapping produces no match, an owner is not assigned. For more information, refer to [Configuring Owner Correlation](<https://documentation.sailpoint.com/saas/help/sources/datasets.html#configuring-owner-correlation>).

## Web Services Datasets

A dataset is a named group of one or more related resources that SailPoint aggregates together.

> [!NOTE]
>
> Web Services is a generic source, so you create your own datasets and resources on the source. Refer to [Creating Datasets](<https://documentation.sailpoint.com/saas/help/sources/datasets.html#creating-datasets>) for more information.

Configure aggregation for each dataset separately. Refer to [Configuring Dataset Aggregations](<https://documentation.sailpoint.com/saas/help/sources/datasets.html#configuring-dataset-aggregations>) for more information.

## Web Services Resources

A resource represents a type of object the connector collects from Web Services, such as agents, applications, or credentials. Each resource defines the attributes collected for that object type and how each object appears in SailPoint.

Refer to [Creating Resources](<https://documentation.sailpoint.com/saas/help/sources/datasets.html#creating-resources>) for more information on creating resources and [Configuring Owner Correlation](<https://documentation.sailpoint.com/saas/help/sources/datasets.html#configuring-owner-correlation>) for more information on linking aggregated objects to their owners.

When you create a resource, select one of the following resource types:

- Agent (`std:agent`)
- Application (`std:application`)
- Capability (`std:capability`)
- Credential (`std:credential`)
- Device (`std:device`)
- Account (`std:account`)

After you create the resource, configure the Resource Aggregation under [HTTP Operations](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html>), then run aggregation.

# Configuring Web Services SaaS Entitlements

## Multiple Group Objects

The Web Services source supports multiple group objects. Add a new endpoint for newly introduced groups or entitlements, such as:

- Group Aggregation - `<GROUP-SCHEMA-OBJECT-TYPE>`
- Get Object - `<GROUP-SCHEMA-OBJECT-TYPE>`
- Add Entitlement - `<GROUP-SCHEMA-OBJECT-TYPE>`
- Remove Entitlement - `<GROUP-SCHEMA-OBJECT-TYPE>`

Refer to the [listSchema](<https://developer.sailpoint.com/docs/api/get-source-schemas-v-1/>) API and [createSchema](<https://developer.sailpoint.com/docs/api/create-source-schema-v-1/>) API for more information.

> [!NOTE]
>
> **Adding a New Group Schema**
>
> To support multi groups, add the following API to add a new schema:
>
> - **Method** - `POST`
> - **URI** - `/sources/<source-id>/schemas`
> - **JSON Payload**:
>
> The following JSON example adds the schema for the Role that follows:
>
> ```json
> {
>     "name": "Role",
>     "nativeObjectType": "Role",
>     "identityAttribute": "Id",
>     "displayAttribute": "Name",
>     "hierarchyAttribute": null,
>     "includePermissions": false,
>     "features": [],
>     "configuration": {},
>     "attributes": [
>         {
>             "name": "Id",
>             "type": "STRING",
>             "schema": null,
>             "description": "Role Id.",
>             "isMulti": false,
>             "isEntitlement": false,
>             "isGroup": false
>         },
>         {
>             "name": "Name",
>             "type": "STRING",
>             "schema": null,
>             "description": "Role name.",
>             "isMulti": false,
>             "isEntitlement": false,
>             "isGroup": false
>         }
>     ]
> }
> ```
>
> The resulting Role:
>
> ```xml
> <Schema displayAttribute="Name" identityAttribute="Id" nativeObjectType="Role" objectType="Role">
> <AttributeDefinition name="Id" type="string">
> <Description>Role Id.</Description>
> </AttributeDefinition>
> <AttributeDefinition name="Name" type="string">
> <Description>Role name.</Description>
> </AttributeDefinition>
> </Schema>
> ```

> [!NOTE]
>
> **Updating the Existing Account Schema**
>
> As the new group schema (for role object type) has been created, update the relevant account schema attributes to point to the new group schema by making changes in the account schema through the UI, as SailPoint allows you to add the new entitlement in the account schema.

> [!NOTE]
>
> **Add New Endpoint**
>
> Add a new endpoint for Group Aggregation, Get Object, and Add/Remove Entitlement operations. Update the `connectionParameters` attribute using the PATCH method as follows:
>
> 1. Add a new dummy endpoint such as Test Connection, Account Aggregation from the SailPoint UI and save it.
> 2. With the PATCH API, replace the required operation type with the respective operation type, such as:
>
>    1. Group Aggregation `<GROUP-SCHEMA-OBJECT-TYPE>`
>    2. Get Object `<GROUP-SCHEMA-OBJECT-TYPE>`
>    3. Add Entitlement `<GROUP-SCHEMA-OBJECT-TYPE>`
>    4. Remove Entitlement `<GROUP-SCHEMA-OBJECT-TYPE>`
>
>       Method - `POST`
>
>       URI - `beta/sources/<source-id>/schemas`
>
>       JSON Payload:
>
>       ```json
>       [
>           {"op":"add","path":"/connectorAttributes/connectionParameters/0/operationType","value":"Group Aggregation-Role"},
>           {"op":"add","path":"/connectorAttributes/connectionParameters/1/operationType","value":"Get Object - Role"},
>           {"op":"add","path":"/connectorAttributes/connectionParameters/2/operationType","value":"Add Entitlement-Role"},
>           {"op":"add","path":"/connectorAttributes/connectionParameters/3/beforeRule","value":"Remove Entitlement-Role"}
>       ]
>       ```

> [!IMPORTANT]
>
> Localization is not applicable for the value of the `OperationType` attribute added from the API. If you provide the operation type in a language other than English, the Web Services source does not configure the group aggregation type (for example, Groepsaggregatie - Rol).

## Configuring Multiple Entitlement Requests

To enable the connector to send multiple entitlement requests of different enlistment types in a single request to the managed system, set the `addRemoveEntInSingleReq` parameter to `true` as follows:

```xml
<entry key="addRemoveEntInSingleReq">
   <value>
       <Boolean>true</Boolean>
   </value>
</entry>
```

You can configure the value of this attribute using the SailPoint REST API. Refer to [SailPoint REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>) for more information.

The following is an example of the payload:

```json
{
  "addRoleIds": $plan.addRoleIds$
}
```

- If `addRemoveEntInSingleReq` is set to `false`, then the placeholder value for the attribute marked as an entitlement is passed in separate API requests:

  First request payload:

  ```text
  jsonBody={ "addRoleIds": "9dd23398-b905-4878-b7ad-bc02d22171d9" }
  ```

  Second request payload:

  ```text
  jsonBody={ "addRoleIds": "8defe39c0-54f6-47b4-8a15-fcc2622923sk" }
  ```
- If `addRemoveEntInSingleReq` is set to `true`, then the placeholder value for the attribute marked as an entitlement is passed as an array and is executed in a single request:

  Single request payload:

  ```text
  jsonBody={ "addRoleIds": ["97ee39c0-54f6-47b4-8a15-fcc262292386","8defe39c0-54f6-47b4-8a15-fcc2622923sk"] }
  ```

## Child Hierarchy

The Web Services SaaS connector supports child hierarchy for entitlements. To achieve this, perform the following:

1. Add the `hierarchyAttribute` property to the entitlementSchemas.
2. Add the `childHierarchy: true` property to the child entitlement.

Refer to the API [Uploads source entitlements schema](<https://developer.sailpoint.com/docs/api/import-entitlements-schema-v-1>) and [Update Source Schema (Partial)](<https://developer.sailpoint.com/docs/api/update-source-schema-v-1/>) in the SailPoint Developer Community for more information.

> [!NOTE]
>
> **Sample Schema**
>
> The following example marks the `roles` attribute on a Role entitlement schema as supporting a child hierarchy:
>
> ```xml
> <Schema displayAttribute="name" identityAttribute="sys_id" nativeObjectType="sys_user_role" objectType="Role">
>   <AttributeDefinition multi="true" name="roles" type="string">
>     <Description>List of roles contained within the role</Description>
>   </AttributeDefinition>
>   <Attributes>
>     <Map>
>       <entry key="childHierarchy" value="true"/>
>     </Map>
>   </Attributes>
> </Schema>
> ```

## Direct Permissions

The Web Services SaaS connector can read direct permissions for accounts. Configure direct permissions using after list account operations in customizers. Refer to [Customizers](<https://documentation.sailpoint.com/connectors/web_services/saas/help/customizers.html>) for more information.

To add direct permissions for accounts, add the desired object to the `permissions` attribute under `StdAccountListOutput` as follows:

```typescript
.afterStdAccountList(async (context: Context, output: StdAccountListOutput) => {
    const permissions = [] as unknown as Permission[];
    const permission = {} as Permission;
    permission.annotation = 'annotationValue';
    permission.rights = 'rightsValue';
    permission.target = 'targetValue';
    output.permissions = permissions;
    return output
})
```

> [!NOTE]
>
> Configuring direct permissions requires additional processing, which may result in an increased duration of time to complete aggregation processes.

# HTTP Operations

In **HTTP Operations**, you can add, edit, delete, and reorder HTTP operations.

The connector supports the following operations:

- Test Connection
- Account Aggregation
- Account Delta Aggregation
- Group Aggregation
- Resource Aggregation - {resourceName}
- Get Object
- Get Object-Group
- Create Account
- Update Account
- Delete Account
- Enable Account
- Disable Account
- Unlock Account
- Change Password
- Add Entitlement
- Remove Entitlement
- Custom Authentication
- Pass-Through Authentication

> [!NOTE]
>
> **Notes**
>
> - For Entitlement Aggregation, you need to configure the schema manually using the REST APIs. Contact SailPoint Support for assistance.
> - For the Web Services source, you can configure the native identity in the provisioning plan using a placeholder such as `$plan.planNativeIdentity$`.
> - Access to ExternalDTD is disabled during XML parsing.

## Support for Cookies

The Web Services source supports cookies for HTTP requests.

The Web Services source supports cookies for multiple endpoints configuration. The source manages the cookies internally for the endpoints configured for the same operation. Cookies from the previous endpoints can be used in all the subsequent endpoints of the same operation type.

The Web Services source supports the JSON array as a top element in the HTTP requests.

By default, the Web Services source supports cookies. Cookies can be disabled by adding the `disableCookies` attribute key with `true` as a value. This is not applicable for the authentication API call operation.

## Add Operations

Configure one or more HTTP operations to manage your source data. The options available to configure the operation vary, depending on your selected **Operation Type**. To add a new HTTP operation, select **Add Operation**.

> [!NOTE]
>
> **Screenshot**
>
> [![Add Operations](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/add_operations.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/add_operations.png>)

The following topics describe the different configuration tabs that may appear when configuring an operation.

### General Information

Enter basic configuration information for the HTTP operation.

> [!NOTE]
>
> **Screenshot**
>
> [![General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/general_information.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/general_information.png>)

1. In the **Operation Name** field, enter a unique name for the operation that you want to execute. You can change the name of an operation later if needed.

   > **Note**
   >
   > SailPoint recommends that you create a unique name for the operation to help you distinguish it from other operations. For example, if you have two account aggregation endpoints for your source, you can name them "Account Aggregation-1" and "Account Aggregation-2".
2. In the **Operation Type** dropdown list, select the name of the operation that you want to execute.

   > **Note**
   >
   > You must configure a Partitioned Account Aggregation operation to support partitioning for static and dynamic. Additionally, to support dynamic partitioning you must also configure a Get Partition operation.
3. Select the **Request Type** from the dropdown.

   If your configuration requires cURL, refer to [Add an Operation with cURL](<#add-an-operation-with-curl>).

   If your configuration requires GraphQL, refer to [Add an Operation with GraphQL](<#add-an-operation-with-graphql>).
4. In the **Context URL** field, enter the authentication (Context) URL specific to your operation. The connector appends the context URL to the source's Base URL. This can be empty depending on the endpoint of the managed system. For example:

   `/2/team/members/list`

   The following are a few keywords that are used in the Context URL along with the placeholder `$`:

   - `plan`
   - `response`
   - `application`
   - `getobject`
   - `authenticate`
5. In the **HTTP Method** field, select the appropriate method from the dropdown list. HTTP method is supported by the respective operation. For example, you can select **GET**, **PUT**, **POST**, **DELETE**, or **PATCH**.
6. Select **Save**.

#### Add an Operation with cURL

The endpoint cURL command for an operation which contains the complete request URL, HTTP Method, Header, and Body is provided in the following example:

```text
curl --location --request POST 'https://api.dropbox.com/2/team/members/list' \
--header 'Authorization: $application.accesstoken$' \
--header 'Content-Type: application/json' \
--data-raw '{"limit":1}'
```

In this example, consider the following:

- Complete request URL: `https://api.dropbox.com/2/team/members/list`

  > **Note**
  >
  > The URL must be in `http://` or `https://` format. You can add a placeholder URL, but it must have `http://` or `https://` at the beginning of the URL string. You can't use a placeholder URL on its own.
- HTTP Method:

  ```text
  POST
  --header 'Authorization: $application.accesstoken$' \
  --header 'Content-Type: application/json' \
  ```
- Header
- Body:

  ```text
  --data-raw '{"limit":1}'
  ```

#### Add an Operation with GraphQL

If you select `GraphQL` as the **Request Type**, the options for **Context URL** and **HTTP Method** are removed, and you only need to provide the **Query** and **GraphQL Variables**.

> [!NOTE]
>
> The connector only supports velocity and placeholder expressions for GraphQL variables.

> [!NOTE]
>
> **Screenshot**
>
> [![Add an Operation with GraphQL](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/add_operation_graphql.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/add_operation_graphql.png>)

The GraphQL for an operation which contains a query and variables is provided in the following example.

##### Query

```text
query ListOrganizationMembers($org: String!, $cursor: String, $first: Int = 100) {
    viewer {
        organization(login: $org) {
            viewerIsAMember
            viewerCanCreateTeams
            membersWithRole(after: $cursor, first: $first) {
                totalCount
                edges {
                    node {
                        login
                        name
                        id
                        email
                        databaseId
                    }
                }
            }
        }
    }
}
```

##### Variables

```json
{
    "org": "sailpoint-sandbox"
}
```

In this example, consider the following:

- The URL is constant throughout the system.
- The HTTP Method is always POST.
- GraphQL supports cursor-based pagination.

### Header

The header holds the key and value for a given HTTP operation that you want to execute. The connector sends these key-value pairs as part of the header in HTTP requests.

> [!NOTE]
>
> **Screenshot**
>
> [![Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/headers.png>)

The following example displays a sample key-value pair, where `Authorization` is the header **Key** and `$application.accesstoken$` is the **Value**.

```text
Authorization - $application.accesstoken$
Content-Type - application/json
```

> [!NOTE]
>
> **Notes**
>
> - If you don't provide the content type in the Header, the source sets Content-Type as `application/json`.
> - If you wish to exclude the default Content-Type header from the requests, add `removeDefaultHeaderFromRequest:true` in the connectionParameter object of those requests using the [put-source](<https://developer.sailpoint.com/docs/api/v3/put-source>) SailPoint Developer Community API.

1. Enter the header **Key** and **Value** used for the operation.
2. Select **Save**.

#### Content Types

- JSON request, JSON response: `Content-Type= application/json (optional), Accept (optional)`

### Body

This is the standard HTTP body used for posting the data with a request. The Body can be configured as one of two types, **Form Data** or **Raw**. Either of these is used for a specific operation.

> [!NOTE]
>
> **Screenshot**
>
> [![Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/body.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/body.png>)

#### Form Data

1. Select **Form Data**.
2. Add the respective data **Key** and **Value**. The Web Services source will not display an error when an endpoint's body type is selected as **Form Data** and the form entries are empty. The key-value pairs are sent as part of the Body in JSON format. XML does not support form data.

#### Raw

1. Select **Raw**.
2. Enter the data in the **Body** field. Select **Save**.

   > **JSON Example**
   >
   > You can use this entry without a placeholder:
   >
   > ```json
   > {
   >     "limit": 10,
   >     "cursor": "abcd1234"
   > }
   > ```
   >
   > You can use this entry with a placeholder:
   >
   > ```json
   > {
   >     "group_id" : "$plan.groups$",
   >     "permission":"$plan.permission$",
   >     "roles": "$plan.roles$"
   > }
   > ```

#### Additional Information for Body

The following keywords are used in the Body along with the placeholder `$`:

- `plan`
- `response`
- `application`
- `getobject`
- `authenticate`

#### Handling the "$" Character in the URL and Body

The Web Services source correctly extracts and handles the `$` character in the URL and Body, along with the placeholders.

#### Placeholder Details

##### The JSON Request with the Placeholder in the Body/Payload

If the body contains a placeholder that is not present in the provisioning plan, response, or source, the source removes the key value from the JSON payload. For example:

```json
{
    "type": "$plan.type$",
    "id": "$plan.nativeIdentity$",
    "title": "$plan.title$",
    "externalid": "12345"
}
```

If the plan does not contain the title attribute request, the source removes the title key and value. For example:

```json
{
    "type": "student",
    "id": "STUD121",
    "externalid": "12345"
}
```

##### URL

If the URL contains a placeholder that is not present in the provisioning plan, response, or source, the source removes the value from the Request URL.

##### Header

If the header contains a value that is not present in the provisioning plan, response, or source, the source removes the key value from the Request Header.

#### Handling the "$$" Character in the URL and Body

The Web Services connector correctly extracts and handles `$$` as a singular velocity operations character in the URL, Body, and Pagination operations.

#### Velocity Details

##### The JSON Request with the Velocity Operations in the Body/Payload

```json
{
    "type": "$$plan.type$$",
    "id": "$$plan.nativeIdentity$$",
    "title": "$$plan.title$$",
    "externalid": "12345"
}
```

> [!NOTE]
>
> Velocity operations can't be configured in XML format.

### Response Information

Response Information has a **Root Path** and a **Success Code**.

> [!NOTE]
>
> **Screenshot**
>
> [![Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/response_information.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/response_information.png>)

The Root Path must be common for all the attributes mentioned in the Response Attribute Mapping for a particular operation.

The Success Code is the successful HTTP response code expected by respective Web Service operations. The Success Code field accepts HTTP status codes in CSV format.

For example, consider the HTTP response code `200, 201, 203`. If the list does not contain any value, the status codes from `200` to `299` are checked. Successful status codes start with `2`.

You can provide `2**` as a Success Code. The Web Services source supports a `null` HTTP response body with custom error messages. For Web Services SaaS, the pagination with a `null` Root Path in Response Mapping works correctly. The default value for root path is `$`.

1. Enter the **Root Path**. This is the common path present in the JSON response. For example:

   - **JSON** - `$.members.profile`
2. Enter the **Success Code**. This is the HTTP success code that serves as a response to the request.
3. Select **Save**.

### Response Mapping

Response Mapping is a response attribute returned in JSON/XML format from the managed system for specific operations like create user, update user, or account aggregation.

> [!NOTE]
>
> **Screenshot**
>
> [![Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/response_mapping.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/response_mapping.png>)

1. Enter the **Schema Attribute** expected in the JSON response from the URL as a part of the schema.
2. Enter the JSON **Attribute Path** of the particular attribute in the returned response. The Root Path is prefixed with this path. For example:

   - **JSON** - `members[*].profile.member_id`
3. Select **Save**.

In the Web Services source, you have to add the schema attributes manually for the respective Web Services-based target system. The source accurately handles any incorrect JSON attribute paths in the endpoint's response mapping configuration.

### XPath Namespace Mapping

Configure the XML **Namespace Prefix** and its corresponding **Namespace URL**, which identify uniquely named elements and attributes in XML requests and responses.

> [!NOTE]
>
> **Screenshot**
>
> [![XPath Namespace Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xpath_namespace_mapping.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xpath_namespace_mapping.png>)

> [!NOTE]
>
> **Notes**
>
> - Absence of non-standard XML Namespaces results in errors while response parsing.
> - If any non-standard XML Namespace exists in the response, configure the same in the XML Namespace mapping where the **Key** is the Namespace Prefix and the **Value** is the Namespace URL.
> - If a default Namespace is present, add a temporary Namespace Prefix with the default Namespace URL in the XML Namespace mappings. Use this temporary prefix in the XPath elements within the scope of the default Namespace.

1. Add the **Namespace Prefix** and **Namespace URL** pair to be used in the XML operation. Use the **Add Another** and **Recycle Bin** options, as needed.
2. Select **Save**.

### Update Considerations

For existing sources, go to the **General Information** tab, select `cURL` from the **Request Type** dropdown if you have configured the cURL Command, otherwise select **API** and then **Save**.

# Integrating SailPoint with Web Services SaaS

The Web Services SaaS connector allows you to configure any Web Services supported managed system that can read and write on the managed system. Web Services SaaS supports REST, SOAP, and GraphQL for read and write.

This document is designed to give specific information about the requirements and fields needed to successfully configure an instance of the Web Services SaaS source.

> [!NOTE]
>
> To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the [SaaS Release Notes](<https://community.sailpoint.com/release-notes/saas>) page.

## Supported Managed Systems

The SailPoint Web Services SaaS connector supports SOAP, REST, and GraphQL web services with XML and JSON response format.

## Prerequisites

- Web Services must be accessible.

## Required Permissions

The user/administrator must have the required permissions to call the Web Services API of the managed system.

## Supported Features

The Web Services SaaS connector supports the following features:

- Account Aggregation
- Account Delta Aggregation
- Partitioning Account Aggregation
- [Child Hierarchy](<https://documentation.sailpoint.com/connectors/web_services/saas/help/entitlements.html#child-hierarchy>)
- [Customizers](<https://documentation.sailpoint.com/connectors/web_services/saas/help/customizers.html>)
- Entitlement Aggregation
- Resource Aggregation - {resourceName}
- Get Object
- Multiple Group Objects
- Provisioning

  - Create Account
  - Add/Remove Entitlement
  - Update Account
  - Enable Account
  - Disable Account
  - Delete Account
  - Unlock Account
  - Change Password

### Authentication

For the Web Services SaaS source, credentials are required to connect to the managed system. The following authentication methods are supported:

- Basic Authentication
- OAuth 2.0 Authentication
- API Token

  > **Note**
  >
  > This source does not generate OAuth tokens based on a Client ID and Client Secret Key. You must provide the API token as an access token.
- No/Custom Authentication
- Pass-through authentication

### Multiple Group Objects

The Web Services SaaS source supports multiple group objects. Refer to [Multiple Group Objects](<https://documentation.sailpoint.com/connectors/web_services/saas/help/entitlements.html#multiple-group-objects>) for more information.

# Keywords

The Web Service source supports the following keywords for various configuration attributes such as Authentication URL, Headers, Body (JSON and Form-data) for a single or multiple endpoints.

## plan

Used for configuring the provisioning operations such as create account and update account. For example:

Authentication URL - `/api/core/v3/people/$plan.nativeIdentity$`

**JSON Body example for plan**:

```json
{"new_members": [
   {
  "email": "$plan.email$",
  "first_name": "$plan.first_name$",
  "surname": "$plan.surname$",
  "send_welcome_email": $plan.send_welcome_email$,
  "role": {
   ".tag": "member_only"
  }
}
]
}
```

## response

Used for multiple endpoints, where the response from the first endpoint is provided as an input for the second endpoint. For example, there are two endpoints for account aggregation:

- The first endpoint returns a response as a list of `member_ids` that is an input for the second endpoint.
- The second endpoint's JSON body is: `{"members_info":[{"member_id":"$response.member_id$"}]}`

## application

Used to get other configuration attributes from the current source. For example:

```text
"$application.<accesstoken>$",
```

Where `<accesstoken>` is a source configuration attribute.

## getobject

Used while performing the `Aggregate Account` operation (get a single account details). The `$getobject` allows you to use any attribute of the account. For example, `$getObject.lastLoginDate$`.

- JSON body:

  ```json
  {"members": [
     {
    ".tag": "member_id",
    "member_id": "$getobject.nativeIdentity$"
  }
  ]
  }
  ```
- Authentication URL for get object:

  ```text
  /api/v4/admin/$getobject.nativeIdentity$
  ```

## nativeIdentity

Indicates the `AccountID` identity attribute in the plan or during the `getobject` operation. For example, `nativeIdentity` is used along with the keyword as follows:

- **getobject** - `$getobject.nativeIdentity$`
- **plan** - `$plan.nativeIdentity$`

> [!NOTE]
>
> There may be instances where `nativeIdentity` is present in the account request for account creation. In such cases, `nativeIdentity` may occasionally reflect different values.

## planNativeIdentity

Represents the Plan's `nativeIdentity` in the Provisioning plan. For example, `planNativeIdentity` is used along with the keyword as follows:

- **plan** - `$plan.planNativeIdentity$`

Web Services can be configured with the native identity from the provisioning plan using the placeholder `$plan.planNativeIdentity$`.

> [!NOTE]
>
> There is a possibility that `nativeIdentity` may be present in the account creation request. It may sometimes correspond to different values.

## authenticate

To provide the username and password in the endpoint configuration, use the following placeholders:

```text
$authenticate.username$
$authenticate.password$
```

Refer to [Pass-Through Authentication](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuring.html#pass-through-authentication>) for more information on configuration.

> [!NOTE]
>
> SailPoint recommends using a placeholder in the body and URL rather than adding sensitive information directly. For example:
>
> ```text
> https://TESTMACHINE:9096/users/user/$application.accesstoken$
> ```
>
> Attributes mapped to a raw JSON response may contain formatted values similar to `".tag": "member_id"`, such as:
>
> ```text
> ['.tag']
> ['@etag']
> ['@@test']
> ['complex.name']
> ['role name']
> ['role_name']
> ```

# JSON and XML Response Examples

This section provides specific examples of the following format responses or inputs for the supported fields or the operations on the Web Services source:

- [JSON Response Examples](<#json-operations>)
- [XML Response Examples](<#xml-operations>)

## JSON Operations

This section provides examples of JSON responses for the supported operations.

### Test Connection

> [!NOTE]
>
> SailPoint recommends that you have a single endpoint set up for test connections because there may be timeout issues for multiple endpoints in test connections.

This topic provides an example of a JSON response for a test connection operation.

> [!NOTE]
>
> **Test Connection Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Test Connection (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Test Connection**.
> 3. In the **Context URL** field, enter the URL specific to the test connection.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Test Connection General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_test.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_test.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs are sent as part of the header in the HTTP request.
>
> [![Test Connection Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_test_connection_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_test_connection_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for a test connection.
>
> In the **Raw** field, enter the JSON payload for the test connection.
>
> [![Test Connection Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_test_connection_body.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_test_connection_body.png>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Test Connection Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_test_connection_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_test_connection_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Below is an example of a schema that is mapped to JSON response. Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information.
>
> [![Test Connection Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_test_connection_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_test_connection_response_map.png>)

### Aggregation

This topic provides an example of a JSON response for an account aggregation operation.

#### Account Aggregation - 1

Using the Web Services SaaS source, you can have multiple account aggregation operations.

For example: Aggregation - 1 and Aggregation - 2.

You can aggregate two attributes from EndPoint1 and three more attributes from EndPoint2.

When you configure multiple operations, the response of first operation can be used as an input in the second operation.

> [!NOTE]
>
> **Account Aggregation - 1 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Account Aggregation - 1 (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Account Aggregation**.
> 3. In the **Context URL** field, enter the URL specific to the account aggregation.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Account Aggregation - 1 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation1.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation1.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Account Aggregation - 1 Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation_header.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation_header.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for an account aggregation.
>
> In the **Raw** field, enter the JSON payload for the account aggregation.
>
> [![Account Aggregation - 1 Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation_body.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation_body.png>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Account Aggregation - 1 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information about the raw JSON response on which the **Response Information** schema is mapped.
>
> [![Account Aggregation - 1 Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation_response_map.png>)

#### Account Aggregation - 2

For example, during aggregation of Dropbox, the response of the first endpoint will return the `id`, `Username`, `firstName`, among others.

This response must be provided as an input to the second endpoint. This can be provided with the help of a keyword "response" (`$response.team_member_id$`), where `team_member_id` is the value fetched from Account Aggregation -1 and it is an identity attribute in the source schema.

> [!NOTE]
>
> **Account Aggregation - 2 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Account Aggregation - 2 (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Account Aggregation**.
> 3. In the **Context URL** field, enter the URL specific to the account aggregation.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Account Aggregation - 2 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Account Aggregation - 2 Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2_header.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2_header.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for an account aggregation.
>
> In the **Raw** field, enter the JSON payload for the account aggregation.
>
> To fetch additional attributes from another endpoint, use the id (identity attribute) from the previous response. Add these attributes in **Schema Attribute** section of **Response Mapping** of the first end point (Account Aggregation - 1).
>
> In the following screenshot, `$response.team_member_id$` represents the identity that was aggregated in the Account Aggregation-1 and is mentioned previously in the schema mapping section of Account Aggregation -1.
>
> [![Account Aggregation - 2 Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2_body.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2_body.png>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Account Aggregation - 2 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Below is an example of a schema that is mapped to XML response. Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information.
>
> [![Account Aggregation - 2 Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2_response_map.png>)
>
> On the **Parent Endpoint** tab:
>
> In the following example, Account Aggregation -1 (JSON) is the parent endpoint and Account Aggregation - 2(JSON) is its child endpoint.
>
> From the **Parent Endpoint Name** dropdown list, select **Account Aggregation - 1 (JSON)**, as shown below.
>
> [![Account Aggregation - 2 Parent Endpoint](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2_parent.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_aggregation2_parent.png>)

#### Account Aggregation - 3

For example, to aggregate users using GraphQL:

> [!NOTE]
>
> **Account Aggregation - 3 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Account Aggregation (GraphQL)`.
> 2. From the **Operation Type** dropdown list, select **Account Aggregation**.
> 3. In the **Request Type** field, select **GraphQL**.
> 4. In the **Query** and **GraphQL Variables** sections, enter the query and variables specific to the account aggregation.
>
> [![Account Aggregation - 3 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql.png>)
>
> On the **Header** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Account Aggregation - 3 Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql1.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql1.png>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** are the successful HTTP response codes expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Account Aggregation - 3 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql_2png.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql_2png.png>)
>
> On the **Response Mapping** tab:
>
> Enter the **Schema Attribute** and **Attribute Path** for JSON response. Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information.
>
> [![Account Aggregation - 3 Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql3.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql3.png>)
>
> On the **XPath Namespace Mapping** tab:
>
> Enter the **Namespace Prefix** and **Namespace URL** for JSON response.
>
> [![Account Aggregation - 3 XPath Namespace Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql_4png.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql_4png.png>)
>
> On the **Parent Endpoint** tab:
>
> From the **Parent Endpoint** dropdown list, select **Account Aggregation(GraphQL)**.
>
> [![Account Aggregation - 3 Parent Endpoint](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql5.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql5.png>)
>
> On the **Paging** tab:
>
> Enter the cursor-based pagination values.
>
> [![Account Aggregation - 3 Paging](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql6.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/gql6.png>)

### Create Account

This topic provides examples of a JSON response for the create account operation.

#### Create Account - 1

> [!NOTE]
>
> **Create Account - 1 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Create Account (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Create Account**.
> 3. In the **Context URL** field, enter the URL specific to the create account operation.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Create Account - 1 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_create_account.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_create_account.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Create Account - 1 Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_create_account_header.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_create_account_header.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for account creation.
>
> In the **Raw** field, enter the JSON payload for the account creation.
>
> In the following screenshot, the `$plan` keyword represents the provisioning plan that is passed to the provision method. For example, `$plan.member_email$` checks for the email in the attribute request and updates in the body after it is found.
>
> [![Create Account - 1 Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_create_account_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_create_account_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Create Account - 1 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_create_account_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_create_account_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information about the raw JSON response on which the **Response Information** schema is mapped.
>
> [![Create Account - 1 Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_create_account_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_create_account_response_map.png>)

#### Create Account - 2

For example, to aggregate users using GraphQL:

> [!NOTE]
>
> **Create Account - 2 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Create Account(GraphQL)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Create Account**.
> 3. In the **Request Type** field, select **GraphQL**.
> 4. Enter the **Query** and **GraphQL Variables** specific to the account aggregation.
>
> [![Create Account - 2 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/ca.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/ca.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Create Account - 2 Header and Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/ca1.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/ca1.png>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Create Account - 2 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/ca2.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/ca2.png>)
>
> On the **Response Mapping** tab:
>
> The following is an example of a schema that is mapped to the JSON response. For more information, refer to to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>).
>
> [![Create Account - 2 Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/ca3.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/ca3.png>)
>
> On the **XPath Namespace Mapping** tab:
>
> Enter the **Namespace Prefix** and **Namespace URL** for JSON response.
>
> [![Create Account - 2 XPath Namespace Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/ca4.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/ca4.png>)

### Add Entitlement

This topic provides an example of a JSON response for an add entitlement operation.

> [!NOTE]
>
> **Add Entitlement Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Add Entitlement (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Add Entitlement**.
> 3. In the **Context URL** field, enter the URL specific to the entitlement.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Add Entitlement General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_add_entitlement.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_add_entitlement.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Add Entitlement Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_add_entitlement_header.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_add_entitlement_header.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for adding entitlements.
>
> In the **Raw** field, enter the JSON payload for the entitlement.
>
> In the following screenshot, the `plan.nativeIdentity` keyword signifies the AccountID (identity attribute) in the account request of the plan. If the plan contains the identity attribute of an account, it can be updated in the payload with `$plan.nativeIdentity$`.
>
> [![Add Entitlement Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_add_entitlement_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_add_entitlement_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Add Entitlement Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_add_entitlement_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_add_entitlement_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information about the raw JSON response on which the **Response Information** schema is mapped.
>
> [![Add Entitlement Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_add_entitlement_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_add_entitlement_response_map.png>)

### Remove Entitlement

This topic provides an example of a JSON response for a remove entitlement operation.

> [!NOTE]
>
> **Remove Entitlement Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Remove Entitlement (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Remove Entitlement**.
> 3. In the **Context URL** field, enter the URL specific to the entitlement.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Remove Entitlement General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_remove_entitlement.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_remove_entitlement.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Remove Entitlement Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_remove_entitlement_header.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_remove_entitlement_header.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for removing entitlements.
>
> In the **Raw** field, enter the JSON payload for the entitlement.
>
> In the following screenshot, the `plan.nativeIdentity` keyword signifies the AccountID (identity attribute) in the account request of the plan. If the plan contains the identity attribute of an account, it can be updated in the payload with `$plan.nativeIdentity$`.
>
> [![Remove Entitlement Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_remove_entitlement_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_remove_entitlement_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Remove Entitlement Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_remove_entitlement_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_remove_entitlement_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information about the raw JSON response on which the **Response Information** schema is mapped.
>
> [![Remove Entitlement Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_remove_entitlement_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_remove_entitlement_response_map.png>)

### Update Account

This topic provides an example of a JSON response for an update account operation.

> [!NOTE]
>
> **Update Account Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Update Account (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Update Account**.
> 3. In the **Context URL** field, enter the URL specific to the account.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Update Account General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_update_account.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_update_account.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Update Account Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_update_account_header.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_update_account_header.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for updating accounts.
>
> In the **Raw** field, enter the JSON payload for the account.
>
> [![Update Account Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_update_account_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_update_account_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Update Account Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_update_account_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_update_account_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information about the raw JSON response on which the **Response Information** schema is mapped.
>
> [![Update Account Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_update_account_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_update_account_response_map.png>)

### Get Object

This topic provides an example of a JSON response for a get object operation.

> [!NOTE]
>
> **Get Object Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Get Object (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Get Object**.
> 3. In the **Context URL** field, enter the URL specific to the get object.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Get Object General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_get_obj.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_get_obj.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Get Object Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_get_object_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_get_object_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for get object.
>
> In the **Raw** field, enter the JSON payload for get object.
>
> In the following screenshot, the `$nativeIdentity$` signifies the AccountID (identity attribute) in the plan or during getObject operation. For example, `nativeIdentity` is used along with the keyword as follows:
>
> getobject: getObject.nativeIdentity
>
> This `$nativeIdentity$` can be used in the Authentication URL.
>
> [![Get Object Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_get_object_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_get_object_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Get Object Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_get_object_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_get_object_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information about the raw JSON response on which the **Response Information** schema is mapped.
>
> [![Get Object Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_get_object_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_get_object_response_map.png>)

### Enable Account

This topic provides an example of a JSON response for an enable account operation.

#### Enable Account - 1

To enable an account using the Web Services SaaS source you may set two operations such as Enable Account -1 and Enable Account - 2. In the first operation (Enable Account -1), the get object can be done and the returned response object is used as the input for the second operation (Enable Account - 2). Refer to the Header and Body of [Enable Account - 2](<#enable-account-2>).

> [!NOTE]
>
> **Enable Account - 1 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Enable Account - 1 (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Enable Account**.
> 3. In the **Context URL** field, enter the URL specific to the account.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Enable Account - 1 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_gen.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_gen.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Enable Account - 1 Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for enabling an account.
>
> In the **Raw** field, enter the JSON payload for the account.
>
> [![Enable Account - 1 Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_body.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_body.png>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Enable Account - 1 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information about the raw JSON response on which the **Response Information** schema is mapped.
>
> [![Enable Account - 1 Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_response_map.png>)

#### Enable Account - 2

> [!NOTE]
>
> **Enable Account - 2 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Enable Account - 2 (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Enable Account**.
> 3. In the **Context URL** field, enter the URL specific to the account.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Enable Account - 2 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account2_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account2_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Enable Account - 2 Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account2_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account2_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for enabling an account.
>
> In the **Raw** field, enter the JSON payload for the account.
>
> [![Enable Account - 2 Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account2_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account2_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Enable Account - 2 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_enable_account_response_info.png>)

### Disable Account

This topic provides an example of a JSON response for a disable account operation.

#### Disable Account - 1

To disable an account using the Web Services SaaS source you must set two operations such as Disable Account -1 and Disable Account - 2. In the first operation (Disable Account -1), the get object is done and the returned object is used as the input for the second operation (Disable Account - 2). Refer to the Header and Body of [Disable Account - 2](<#disable-account-2>).

> [!NOTE]
>
> **Disable Account - 1 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Disable Account - 1 (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Disable Account**.
> 3. In the **Context URL** field, enter the URL specific to the account.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Disable Account - 1 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Disable Account - 1 Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for disabling an account.
>
> In the **Raw** field, enter the JSON payload for the account.
>
> [![Disable Account - 1 Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account_body.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account_body.png>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Disable Account - 1 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account_general_info.png>)
>
> On the **Response Mapping** tab:
>
> Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information about the raw JSON response on which the **Response Information** schema is mapped.
>
> [![Disable Account - 1 Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account_response_map.png>)

#### Disable Account - 2

> [!NOTE]
>
> **Disable Account - 2 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Disable Account - 2 (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Disable Account**.
> 3. In the **Context URL** field, enter the URL specific to the account.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Disable Account - 2 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account2_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account2_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Disable Account - 2 Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account2_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account2_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for disabling an account.
>
> In the **Raw** field, enter the JSON payload for the account.
>
> [![Disable Account - 2 Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account2_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account2_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Disable Account - 2 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_disable_account_response_info.png>)

### Change Password

This topic provides an example of a JSON response for a change password operation.

> [!NOTE]
>
> **Change Password Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Change Password (JSON)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Chance Password**.
> 3. In the **Context URL** field, enter the URL specific to the change password operation.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Change Password General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_change_pass.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_change_pass.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Change Password Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_change_password_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_change_password_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. You can use either of them for changing a password.
>
> In the **Raw** field, enter the JSON payload for the password change.
>
> [![Change Password Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_change_password_body.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_change_password_body.png>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Change Password Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_change_password_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_change_password_response_info.png>)

## XML Operations

This section provides examples of XML responses for the supported operations.

### Test Connection

This topic provides an example of an XML response for a test connection operation.

> [!NOTE]
>
> **Test Connection Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Test Connection (XML)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Test Connection**.
> 3. In the **Context URL** field, enter the URL specific to the test connection.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Test Connection General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_test_connection_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_test_connection_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs are sent as part of header in the HTTP request.
>
> [![Test Connection Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_test_connection_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_test_connection_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. The XML format does not support **Form Data**.
>
> In the **Raw** field, enter the XML payload for the test connection.
>
> [![Test Connection Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_test_connection_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_test_connection_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the XML response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Test Connection Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_test_connection_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_test_connection_response_info.png>)

### Account, Entitlement, or Get Object Aggregation

This topic provides an example of an XML response for an aggregation operation.

#### Account Aggregation - 1

Using the Web Services SaaS source, you can have multiple account aggregation operations.

For example: Aggregation - 1 and Aggregation - 2.

You can aggregate two attributes from EndPoint1 and three more attributes from EndPoint2.

When you configure multiple operations, the response of first operation can be used as an input in the second operation.

> [!NOTE]
>
> **Account Aggregation - 1 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Account Aggregation - 1 (XML)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Account Aggregation**.
> 3. In the **Context URL** field, enter the URL specific to the account aggregation.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Account Aggregation - 1 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Account Aggregation - 1 Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. The XML format does not support **Form Data**.
>
> In the **Raw** field, enter the XML payload for the account aggregation.
>
> [![Account Aggregation - 1 Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the XML response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Account Aggregation - 1 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Below is an example of a schema that is mapped to XML response. Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information.
>
> [![Account Aggregation - 1 Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_response_map.png>)
>
> On the **XPath Namespace Mapping** tab:
>
> The namespace **xmlns** is the default namespace for the example mentioned in this section, and it is represented as **ns** in the following screenshot.
>
> [![Account Aggregation - 1 XPath Namespace Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_xpath.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation_xpath.png>)

#### Account Aggregation - 2

For example, during aggregation of Dropbox, the response of the first endpoint will return `id`, `Username`, `firstName`, among others.

This response must be provided as an input to the second endpoint, this can be provided with help of a keyword "response" (`$response.team_member_id$`), where the `team_member_id` is the value fetched from Account Aggregation -1 and it is an identity attribute in the source schema.

> [!NOTE]
>
> **Account Aggregation - 2 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Account Aggregation - 2 (XML)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Account Aggregation**.
> 3. In the **Context URL** field, enter the URL specific to the account aggregation.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Account Aggregation - 2 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Account Aggregation - 2 Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. The XML format does not support **Form Data**.
>
> In the **Raw** field, enter the XML payload for the account aggregation.
>
> To fetch additional attributes from another endpoint, use the `id` (identity attribute) from the previous response. Add these attributes in **Schema Attribute** section of **Response Mapping** of the first end point (Account Aggregation - 1).
>
> In the following screenshot the `$response.team_member_id$` represents the identity that was aggregated in Account Aggregation-1 and mentioned in the schema mapping section of Account Aggregation -1.
>
> [![Account Aggregation - 2 Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the XML response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Account Aggregation - 2 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Below is an example of a schema that is mapped to XML response. Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information.
>
> [![Account Aggregation - 2 Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_response_map.png>)
>
> On the **XPath Namespace Mapping** tab:
>
> The namespace **xmlns** is the default namespace for the example mentioned in this section, and it is represented as **ns** in the following screenshot.
>
> [![Account Aggregation - 2 XPath Namespace Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_xpath.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_xpath.png>)
>
> On the **Parent Endpoint** tab:
>
> In the following example, Account Aggregation -1 (JSON) is the parent endpoint and Account Aggregation - 2(JSON) is its child endpoint.
>
> From the **Parent Endpoint Name** dropdown list, select **Account Aggregation - 1 (JSON)**, as shown below.
>
> [![Account Aggregation - 2 Parent Endpoint](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_parent.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_account_aggregation2_parent.png>)

### Create Account

This topic provides an example of an XML response for a create account operation.

> [!NOTE]
>
> **Create Account Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Create Account (XML)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Create Account**.
> 3. In the **Context URL** field, enter the URL specific to the account creation.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Create Account General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Create Account Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. The XML format does not support **Form Data**.
>
> In the **Raw** field, enter the XML payload for the account creation.
>
> In the following screenshot, the `$plan` keyword represents the Provisioning Plan that is passed to the provision method. For example, `$plan.LastName` checks for the last name in the attribute request and updates in the body after it is found.
>
> [![Create Account Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the XML response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Create Account Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Below is an example of a schema that is mapped to XML response. Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information.
>
> [![Create Account Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_response_map.png>)
>
> On the **XPAth Namespace Mapping** tab:
>
> The namespace **xmlns** is the default namespace for the example mentioned in this section, and it is represented as **ns** in the following screenshot.
>
> [![Create Account XPAth Namespace Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_xpath.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_create_account_xpath.png>)

### Account Delta Aggregation

This topic provides an example of an XML response for the delta aggregation operation.

#### Account Delta Aggregation - 3

Using the Web Services SaaS source, you can perform account delta aggregation operations.

> [!NOTE]
>
> **Account Delta Aggregation - 3 Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Account Aggregation - 3` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Account Delta Aggregation**.
> 3. In the **Context URL** field, enter the URL specific to the account delta aggregation. For example, the URL specified in the context URL is `/users?filter=meta.lastModifiedDate gt "$application.lastAggregationDate_account$"` ; where the `lastAggregationDate_account` is the last successful aggregation timestamp.
>
>    > **Note**
>    >
>    > The default time period is in format: "`yyyy-MM-dd'T'kk:mm:ss'Z'`" If you want to change the time period format, use the following key-value pair to update the source via API: **key**: `connector_dateTimePattern`**value**: "`yyyy-MM-dd'T'kk:mm:ss'Z'`" **key** : `connector_serverTimeZone`**value**: "`UTC`"
> 4. In the **HTTP Method** dropdown list, select **GET**.
>
> [![Account Delta Aggregation - 3 General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_delta_aggregation.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_delta_aggregation.png>)
>
> On the **Headers** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Account Delta Aggregation - 3 Headers](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_headers_delta_aggr.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_headers_delta_aggr.png>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the JSON response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Account Delta Aggregation - 3 Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_response_delta_aggr.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_response_delta_aggr.png>)
>
> On the **Response Mapping** tab:
>
> Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information about the raw JSON response on which the **Response Information** schema is mapped.
>
> [![Account Delta Aggregation - 3 Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_response_map_delta_aggr.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_response_map_delta_aggr.png>)
>
> On the **XPath Namespace Mapping** tab:
>
> The namespace **xmlns** is the default namespace for the example mentioned in this section, and it is represented as **ns**.
>
> [![Account Delta Aggregation - 3 XPath Namespace Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_namespace_delta_aggregation_exp.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_namespace_delta_aggregation_exp.png>)
>
> On the **Parent Endpoint** tab:
>
> From the **Parent Endpoint Name** dropdown list, if needed select the endpoint on which the current operation is dependent to process the request.
>
> [![Account Delta Aggregation - 3 Parent Endpoint](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_parent_endpoint_delta_aggr.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_parent_endpoint_delta_aggr.png>)
>
> On the **Paging** tab:
>
> 1. In the **Initial Page Offset**, select the page offset required.
> 2. From the **Page Size**, select the required page size for delta aggregation.
> 3. In the **Paging Steps** field, enter any necessary paging steps defined.
>
> [![Account Delta Aggregation - 3 Paging](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_paging_delta_aggr.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/json_paging_delta_aggr.png>)

### Get Object

This topic provides an example of an XML response for a get object operation.

> [!NOTE]
>
> **Get Object Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Get Object (XML)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Get Object**.
> 3. In the **Context URL** field, enter the URL specific to the get object.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Get Object General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Get Object Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. The XML format does not support **Form Data**.
>
> In the **Raw** field, enter the XML payload for the get object.
>
> The `$nativeIdentity$` signifies the AccountID (identity attribute) in the plan or during the get object operation. For example, `nativeIdentity` is used along with the following keywords:
>
> - **getobject** - `$getObject.nativeIdentity$`
> - **plan** - `$plan.nativeIdentity$`
>
> [![Get Object Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the XML response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Get Object Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_response_info.png>)
>
> On the **Response Mapping** tab:
>
> Below is an example of a schema that is mapped to XML response. Refer to [Configuration for Response](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuration_parameters.html#configuration-for-response>) for more information.
>
> [![Get Object Response Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_response_map.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_response_map.png>)
>
> On the **XPath Namespace Mapping** tab:
>
> The namespace **xmlns** is the default namespace for the example mentioned in this section, and it is represented as **ns** in the following screenshot.
>
> [![Get Object XPath Namespace Mapping](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_xpath.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_get_object_xpath.png>)

### Add Entitlement

This topic provides an example of an XML response for an add entitlement operation.

> [!NOTE]
>
> **Add Entitlement Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Add Entitlement (XML)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Add Entitlement**.
> 3. In the **Context URL** field, enter the URL specific to the entitlement.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Add Entitlement General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_add_entitlement_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_add_entitlement_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Add Entitlement Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_add_entitlement_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_add_entitlement_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. The XML format does not support **Form Data**.
>
> In the **Raw** field, enter the XML payload for the entitlement.
>
> [![Add Entitlement Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_add_entitlement_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_add_entitlement_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the XML response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Add Entitlement Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_add_entitlement_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_add_entitlement_response_info.png>)

### Enable Account

This topic provides an example of an XML response for an enable account operation.

> [!NOTE]
>
> **Enable Account Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Enable Account (XML)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Enable Account**.
> 3. In the **Context URL** field, enter the URL specific to the account.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Enable Account General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_enable_account_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_enable_account_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Enable Account Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_enable_account_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_enable_account_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. The XML format does not support **Form Data**.
>
> In the **Raw** field, enter the XML payload for the account.
>
> Here the `plan.nativeIdentity` keyword signifies the AccountID (identity attribute) in the account request of the plan. For example, `nativeIdentity` is used along with the following keywords:
>
> - **getobject** - `$getObject.nativeIdentity$`
> - **plan** - `$plan.nativeIdentity$`
>
> > **Note**
> >
> > If the target system expects the complete account object as payload, you must write a Before Operation Rule to fetch the complete object details and update the body attribute endpoint. Refer to Web Services Before Operation Rule for more information.
>
> [![Enable Account Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_enable_account_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_enable_account_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the XML response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Enable Account Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_enable_account_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_enable_account_response_info.png>)

### Disable Account

This topic provides an example of an XML response for a disable account operation.

> [!NOTE]
>
> **Disable Account Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Disable Account (XML)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Disable Account**.
> 3. In the **Context URL** field, enter the URL specific to the account.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Disable Account General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_disable_account_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_disable_account_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Disable Account Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_disable_account_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_disable_account_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. The XML format does not support **Form Data**.
>
> In the **Raw** field, enter the XML payload for the account.
>
> Here the `plan.nativeIdentity` keyword signifies the AccountID (identity attribute) in the account request of the plan. For example, `nativeIdentity` is used along with the following keywords:
>
> - **getobject** - `$getObject.nativeIdentity$`
> - **plan** - `$plan.nativeIdentity$`
>
> [![Disable Account Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_disable_account_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_disable_account_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the XML response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Disable Account Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_disable_account_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_disable_account_response_info.png>)

### Update Account

This topic provides an example of an XML response for a disable account operation.

> [!NOTE]
>
> **Update Account Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Update Account (XML)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Update Account**.
> 3. In the **Context URL** field, enter the URL specific to the account.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Update Account General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_update_account_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_update_account_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Update Account Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_update_account_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_update_account_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. The XML format does not support **Form Data**.
>
> In the **Raw** field, enter the XML payload for the account.
>
> [![Update Account Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_update_account_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_update_account_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the XML response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Update Account Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_update_account_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_update_account_response_info.png>)

### Change Password

This topic provides an example of an XML response for a disable account operation.

> [!NOTE]
>
> **Change Password Example**
>
> On the **General Information** tab:
>
> 1. In the **Operation Name** field, enter `Change Password (XML)` as the operation name.
> 2. From the **Operation Type** dropdown list, select **Change Password**.
> 3. In the **Context URL** field, enter the URL specific to the password change.
> 4. In the **HTTP Method** dropdown list, select **POST**.
>
> [![Change Password General Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_change_password_general_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_change_password_general_info.png>)
>
> On the **Header and Body** tab:
>
> The Header has the data keys and their corresponding values. These key value pairs will be sent as part of the Header in the HTTP Request.
>
> [![Change Password Header](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_change_password_headers.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_change_password_headers.png>)
>
> The HTTP body is used for posting the data with a request. The body has two data entry types, **Form Data** and **Raw**. The XML format does not support **Form Data**.
>
> In the **Raw** field, enter the XML payload for the account.
>
> [![Change Password Body](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_change_password_body.gif>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_change_password_body.gif>)
>
> On the **Response Information** tab:
>
> The **Root Path** is the common path present in the XML response. The **Success Code** is the successful HTTP response code expected by the respective Web Service operation. By default, the success code is `2**`.
>
> [![Change Password Response Information](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_change_password_response_info.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/xml_change_password_response_info.png>)

# Pagination

Web Services supports generic paging for Account and Entitlement Aggregations.

> [!NOTE]
>
> **Notes**
>
> - If there are multiple Account or Entitlement Aggregation operations (endpoints) configured, paging is supported only for the first operation instance of Account or Entitlement Aggregation.
> - By default, the page size is 50 and page offset is 0.
> - The Web Services source correctly evaluates the `)` character within a string in the paging configuration.

## Configure Paging

Paging can be configured in Account/Entitlement Aggregation endpoints using the **Paging** tab with one of the following methods:

- Paging based on limit-offset
- Paging based on response markers
- Paging based on response header links

> [!NOTE]
>
> The **Paging** tab becomes available when you configure certain HTTP operations, such as account and entitlement aggregation. Refer to [Configuring Paging as an HTTP Operation](<#configuring-paging-as-an-http-operation>) for more information on configuring paging as an HTTP operation.

### Configuration Considerations

Consider the following while configuring paging in the **Paging** tab:

- Every paging configuration step must start on a new line.
- SailPoint recommends providing a space after every operator, condition, or placeholder for correct evaluation of the paging expression.
- The paging mechanism follows the placeholder notation for resolution of attribute values:

  ```text
  $response.attribute_key$
  ```

  Any attribute which follows the placeholder notation is resolved or assigned a value depending upon the operator being used.
- Intermediate values can also be stored between page requests by using the placeholder notation. To achieve this, any attribute key which does not match any of the predefined keywords can be used. For more information, see the example in [Paging Based on Limit-Offset](<#paging-based-on-limit-offset>) where `$sysparm_offset$` is updated and used between page requests.
- For complex expressions or conditions, multiple conditions can be grouped together using parentheses. For example:

  ```text
  TERMINATE_IF ($someattribute$ == TRUE) && ($otherattribute$ == NULL)
  ```

> [!IMPORTANT]
>
> For more information and implementation of paging, contact SailPoint Services.

### Paging Keywords

The paging mechanism has the following predefined set of keywords you can use:

| Keyword | Description |
| --- | --- |
| `application` | Represents the application. `baseUrl` - Base URL configured in the source. |
| `endpoint` | Represents endpoint configuration. `relativeURL` - Relative URL of the endpoint. `fullUrl` - Full URL contained within the endpoint. |
| `limit` | Indicates page limit configured in the endpoint configuration. |
| `offset` | Indicates page offset configured in the endpoint configuration. |
| `request` | Represents request body. |
| `requestHeaders` | Represents request header. |
| `response` | Represents response body object. |
| `responseHeaders` | Represents response header. |
| `TERMINATE_IF` | Indicates termination condition; multiple conditions can exist. `NO_RECORDS` - Indicates no records retrieved; to be used in conjunction with `TERMINATE_IF`, evaluates to TRUE/FALSE. `RECORDS_COUNT` - Indicates number of records retrieved. |
| `NULL` | Indicates null or empty object. |
| `REMOVE` | Indicates to remove an attribute. |

> [!IMPORTANT]
>
> Avoid using arithmetic operations in the `TERMINATE_IF` statement. Arithmetic statements should be performed before checking for termination conditions.

### Supported Operators

| Type | Operations |
| --- | --- |
| Regular operations | `+`, `-`, `*`, `/`, `=`, `&&`, and `\|\|` |
| Conditional operations | `<`, `>`, `<=`, `>=`, `==`, and `!=` |

### Paging Based on Request Body Configuration

Configure paging using request body parameter configuration.

For example, an initial aggregation URL for an example managed system is as follows:

```text
https://test.com/GetUserList
```

The example URL has the following parameters:

- **baseUrl** - `https://test.com`
- **relativeURL** - `/GetUserList`

The request body is as follows:

```text
Body: {
    "Limit" : 50,
    "offset": 1
}
```

Use the following configuration steps on the **Paging** tab based on the request body:

```text
$limit$ = 50
TERMINATE_IF $RECORDS_COUNT$ < $limit$
$offset$ = $offset$ + 1
$endpoint.fullUrl$ = $application.baseUrl$ + "/GetUserList"
$request.PageIndex$ = $offset$
```

### Paging Based on Limit-Offset

You can limit pagination based on the `$offset$` and `$limit$` placeholders.

- `$offset$` - Initial page offset
- `$limit$` - Page size

For example, in the following configuration, the maximum number of users to fetch per page is 100, and the starting offset of the API is 0. The index in the subsequent page is 101.

1. In **General Information \> Context URL**, enter the following:

   ```text
   /v2/users?pageSize=$limit$&index=$offset$
   ```
2. Go to the **Paging** tab and set the following:

   - **Page Size** - `100`
   - **Initial Page Offset** - `0`
3. Configure the following in **Paging Steps**:

   ```text
   TERMINATE_IF $RECORDS_COUNT$ < $limit$
   $offset$ = $offset$ + $limit$
   $endpoint.fullUrl$ = $application.baseUrl$ + "/v2/users?pageSize=" + $limit$ + "&index=" + $offset$
   ```

#### Managed System Specific Configurations

This section describes paging based on limit-offset for ServiceNow and Workday managed systems.

##### For ServiceNow

For example, the initial aggregation URL for a ServiceNow managed system is as follows:

```text
https://XYZ.service-now.com/api/now/v1/table/sys_user?sysparm_limit=100&sysparm_fields=sys_id
```

The above URL includes the following parameters:

- **baseUrl** - `https://XYZ.service-now.com`
- **relativeURL** - `api/now/v1/table/sys_user?sysparm_limit=100&sysparm_fields=sys_id`

To configure paging based on limit-offset:

1. Use the following for a ServiceNow managed system:

   ```text
   TERMINATE_IF $RECORDS_COUNT$ < $sysparm_limit$
   $sysparm_offset$ = $sysparm_offset$ + $sysparm_limit$
   $endpoint.fullUrl$ = $application.baseUrl$ + "/api/now/v1/table/sys_user?sysparm_fields=sys_id&sysparm_limit=100&sysparm_offset=" + $sysparm_offset$
   ```

   In this example, the maximum record count is set using `sysparm_limit` and `RECORDS_COUNT`. `RECORDS_COUNT` represents the number of records fetched from the response and `sysparm_limit` can be changed as required. Based on this step, the next page URL is as mentioned in the following steps.
2. The second page URL is based on the paging steps configuration:

   ```text
   https://XYZ.com/api/now/v1/table/sys_user?sysparm_limit=100&sysparm_fields=sys_id&sysparm_offset=100
   ```
3. The next page URL is based on the paging steps configuration:

   ```text
   https://XYZ.com/api/now/v1/table/sys_user?sysparm_limit=100&sysparm_fields=sys_id&sysparm_offset=200
   ```

The paging operation is terminated when `RECORDS_COUNT` is less than `sysparm_limit`, as follows:

```text
$RECORDS_COUNT$ < $sysparm_limit$
```

##### For Workday

For example, the initial aggregation URL for a Workday managed system is as follows:

```text
https://XYZ.workday.com/ccx/service/sailpoint_pt1/Human_Resources/v24.1
```

The above URL includes the following parameters:

- **baseUrl** - `https://XYZ.workday.com`
- **relativeURL** - `/ccx/service/sailpoint_pt1/Human_Resources/v24.1`

The following are the configuration steps in the paging tab based on limit-offset:

1. Use the following for a Workday managed system:

   ```text
   TERMINATE_IF $response.wd:Response_Results.wd:Page$ > $response.wd:Response_Results.wd:Total_Pages$
   $offset$ = $response.wd:Response_Results.wd:Page$ + 1
   $request.bsvc:Response_Filter.bsvc:Page.text()[1]$ = $offset$
   ```

   In the above example, the number of pages is verified with the response from Workday and compared with the total number of pages. If the current page number is less than the total pages, then the request body (SOAP Body) is updated with the new page by incrementing it.

   The following is an example of an initial payload request with Initial Page Size (the initial page is the beginning index) as 1 and Page Size (number of records per page) as 10:

   ```xml
   <soapenv:Body>
   <bsvc:Get_Workers_Request bsvc:version="v24.1">
   <bsvc:Request_Criteria>
             ....
             </bsvc:Request_Criteria>
            <bsvc:Response_Filter>
     <bsvc:Page>1</bsvc:Page>
     <bsvc:Count>10</bsvc:Count>
   </bsvc:Response_Filter>

           <bsvc:Response_Group>
             ....
           </bsvc:Response_Group>
           </bsvc:Get_Workers_Request>
      </soapenv:Body>
   ```
2. Based on the previous paging step, the next payload is as follows. The second aggregation payload increments the offset (page number):

   ```xml
   <soapenv:Body><bsvc:Get_Workers_Request bsvc:version="v24.1">
   <bsvc:Request_Criteria>
             ....
             </bsvc:Request_Criteria>
            <bsvc:Response_Filter>
     <bsvc:Page>2</bsvc:Page>

     <bsvc:Count>10</bsvc:Count>
   </bsvc:Response_Filter>

           <bsvc:Response_Group>
             ....
           </bsvc:Response_Group>
           </bsvc:Get_Workers_Request>
      </soapenv:Body>
   ```

### Paging Based on Response Markers

This section describes paging based on a marker value in the response. Based on the marker value in the response, an aggregation process is terminated or continued.

The following table lists examples of response marker based paging for Dropbox, Salesforce, and SuccessFactors.

> [!NOTE]
>
> Other managed systems may use different response marker formats. In some configurations, it may be better to use the Before or After Operation Rule to configure paging.

#### Dropbox

```text
TERMINATE_IF $response.has_more$ == FALSE

$endpoint.fullUrl$ = $application.baseUrl$ + $endpoint.relativeUrl$ + "/continue"

$request.cursor$ = $response.cursor$

REMOVE $request.limit$
```

#### Salesforce

```text
TERMINATE_IF $response.ns:result.ns:done$ != FALSE

$request.soapenv:Body$ = "<urn:queryMore><urn:queryLocator>" + $response.ns:result.ns:queryLocator$ + "</urn:queryLocator></urn:queryMore>"
```

#### SuccessFactors

```text
TERMINATE_IF $response.ns:result.ns:hasMore$ != TRUE

$request.soapenv:Body$ = "<urn:queryMore><urn:querySessionId>" + $response.ns:result.ns:querySessionId$ + "</urn:querySessionId></urn:queryMore>"
```

### Paging Based on Response Header Links

This section describes paging based on response header links.

The following table lists examples of response header links-based paging for ServiceNow, and Okta managed systems.

> [!NOTE]
>
> Other managed systems may use different response header link formats. In some configurations, it may be better to use the Before or After Operation Rule to configure paging.

#### ServiceNow

```text
TERMINATE_IF $responseHeaders.link.next$ == NULL

$endpoint.fullUrl$ = $responseHeaders.link.next$
```

#### Okta

```text
TERMINATE_IF $responseHeaders.link.next$ == NULL

$endpoint.fullUrl$ = $responseHeaders.link.next$
```

### Paging Based on lastRecord

The Web Services SaaS connector can support pagination by dynamically injecting a value from one response into the response that immediately follows it using the `lastRecordAttribute` attribute and the `$lastRecord$` placeholder. Add `lastRecordAttribute` to `connectorAttributes`.

- `lastRecordAttribute` - Defines the attribute (key) from the response records whose value is used as the starting point for the next page. Type: String. Default value: `id`.

Pagination continues until no records are returned. For example:

```text
TERMINATE_IF $NO_RECORDS$
```

The endpoint URL is constructed dynamically using placeholders:

```text
$endpoint.fullUrl$ = $application.baseUrl$ + "/v1/$application.appId$/users?limit=" + $limit$ + "&startingAfter=" + $lastRecord$
```

The connector checks for the `$lastRecord$` placeholder in the paging configuration. During response aggregation, it does the following:

1. References the last record in the current page of the response.
2. Extracts the value of the field specified in `lastRecordAttribute`. For example, you can configure this as the `id` attribute.
3. In the next page, replaces the `$lastRecord$` placeholder in the URL with the extracted value.

For example, if the last record in a page has:

```json
{ "id": "abc123", "name": "John Doe" }
```

And `lastRecordAttribute` is `"id"`, then the next request URL includes the following:

```text
&startingAfter=abc123
```

To configure this feature, enter the attribute name you want to use as a page delimiter as the `lastRecordAttribute` attribute value in the source XML file via the REST API.

> [!NOTE]
>
> Refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>) in the SailPoint Developer Community for more information on SailPoint's REST APIs.

## Configuring Paging as an HTTP Operation

Configure paging as an HTTP operation. The **Paging** option appears for aggregation operations.

Refer to [Pagination](<#pagination>) for more information on the paging feature.

> [!NOTE]
>
> **Screenshot**
>
> [![Paging](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/http_paging.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/http_paging.png>)

1. Set the **Initial Page Offset**, which sets the page offset configured in the endpoint configuration.
2. Set the **Page Size**, which determines how many records the connector displays on each page.
3. In **Paging Steps**, enter configuration steps as required for limit-offset, response markers, or response header links paging.
4. Select **Save**.

# Partitioning

Web Services supports partitioning through the following modes:

- **Static Partitioning** - Defines the separate partitions through fixed mappings via API from the backend only.

  > **Note**
  >
  > Use the [SailPoint Beta SaaS API](<https://developer.sailpoint.com/docs/api/>) to update the source with Static Partitions along with other configuration.
- **Dynamic Partitioning** - Discovers partitions at run time based on information returned by a REST or Web Services API call from a remote system.

Static and Dynamic partitioning modes can be used at the same time. Partitions can be defined both in fixed configuration blocks and by dynamic values returned from the remote system. When both types of configurations are used, the list of partition records is concatenated and all of the defined partitions are aggregated.

Conceptually, each partition retrieves the accounts from the managed system that correspond to a specific field or field values. The connector expects that those values can be passed to a search or filter API exposed by the managed system. The connector supports partitioning through token substitution of a URL pattern and/or a POST payload body's JSON or XML.

For example, the Acme Human Resources department groups account searches by their costCenter attribute, and configures the API to return accounts using the following configuration:

```text
GET https://acme-hr.com/admin/listAccounts?costCenter=AdminHQ
```

In this example, the API returns account records which belong only to the "AdminHQ" cost center.

Assuming an even distribution of accounts to various costCenter values, each value for the costCenter attribute in this example can be mapped to a partition that aggregates the accounts corresponding to that grouping. Each partition is effectively a map of key-value pairs that define a unique grouping of accounts.

The partition's key-value pairs are exposed to the Before/After Rules of a Connector Operation. They are available in the **Context URL** field, which is appended to the request, and in the body text of a POST operation. In the Context URL, the partition to aggregate is exposed as the `$partition.*$` keyword, where the asterisk (`*`) is replaced by the field name from the partition. This behaves similarly to the `$response.*` keyword and other tokens used by the Web Services connector.

For example, in a partitioned account aggregation type of operation, you could have a Context URL as follows:

```text
https://acme-hr.com/admin/listAccounts?costCenter=$partition.costCenter$
```

When evaluated during aggregation, the partition's costCenter value is substituted for the $-encapsulated field and is then passed to the remote system. In situations where a simple path substitution is not sufficient, the URL can be generated in the Before Operation Rule by modifying the request endpoint's **URL** field. The partition variable is exposed in the Before Operation Rule for use by connector-specific rule logic.

## Partitioning Settings

Configure partitioning aggregation to enable parallel data processing across multiple threads, enhancing the performance of aggregation tasks. Refer to [Partitioning](<#partitioning>) for information on configuration.

> [!NOTE]
>
> **Screenshot**
>
> [![Partitioning Settings](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/partitioning_settings.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/partitioning_settings.png>)

1. Select **Enable Partition Aggregation**.
2. In the **User Partitions** field, define the User Partitioning Scheme. Press the Enter key to add each partitioning scheme to a growing list.
3. Select **Save**.

## Partitioning Operations

Partition Aggregation is supported by the following operation types:

- Get Partitions
- Partitioned Account Aggregation

You must configure a **Get Partition** type connector operation to support dynamic partitioning.

You must configure a **Partitioned Account Aggregation** connector operation to support static and dynamic partitioning. The Partitioned Account Aggregation operation is similar to the Account Aggregation endpoint. The only difference between the two is that the Partitioned Account Aggregation operation invokes when Account Aggregation with partitioning is enabled. The Partitioned Account Aggregation receives the `$partition.$` keyword tokens, but the original operation does not. Having these two as separate operations allows the connector to support single-threaded and partitioned (multi-threaded) aggregations with one configuration.

## Configuring Static Partitions

Static partition configuration can be configured using v3 APIs. You can configure static partitions using JSON, and upload it using SailPoint's REST API.

> [!NOTE]
>
> Refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>) in the SailPoint Developer Community for more information on SailPoint's REST APIs.

The following example displays two static partitions that are identified by different `costCenter` values:

```json
[
    {
        "op": "add",
        "path": "/connectorAttributes/partitions",
        "value": [
            {
                "name": "Partition 1",
                "size": 0,
                "attributes": {
                    "costCenter": "CC-AD"
                }
            },
            {
                "name": "Partition 2",
                "size": 0,
                "attributes": {
                    "costCenter": "CC-AE"
                }
            }
        ]
    }
]
```

## Configuring Dynamic Partitioning

When invoked, the Get Partitions operation returns a list of partition records. This is a top-level operation which can be chained by referring to its Parent Operation.

For example, a web service that returned the list of unique cost centers inside an HR application from an API request is as follows:

```text
GET https://hr.acme.com/admin/listCostCenters

{
"idList": [
"CC-00",
"CC-AA",
"CC-AAZY",
...
"CC-AZYXWVUT",
"CC-AZYXWVUTS"
]
}
```

In this example, the JSON payload returns an `idList` that contains an array of string values, and each is a Cost Center name. A Get Partitions operation must be configured to handle this JSON response. The relevant fields are:

- **Context URL** - `/admin/listCostCenters`
- **Method** - `GET`
- **Response - Root Path** - `$.idList.*`
- **Response - Schema Attribute** - `costCenter` Attribute Path: `$`
- **Response - Schema Attribute** - `name` Attribute Path: `$`

By passing the string to the partition's name and the costCenter attribute, the partition's name is rendered cleanly in the Aggregation Task's status interface. Partitions with no assigned name are randomly assigned a UUID value as their name.

When the aggregation is performed and partitioning is enabled, it first asks the connector what dynamic partitions it has. The connector then calls this Get Partitions operation and returns the list of partition maps to the aggregation process. Each partition has a `costCenter` field and a name field populated for use in the aggregation operation.

## Configuring Partitioned Account Aggregation Operation

The Partitioned Account Aggregation connector operation is invoked once for each partition map. The Partitioned Account Aggregation is conceptually very similar to the regular Account Aggregation operation and serves the same function. The only difference is the Partitioned Account Aggregation operation is always invoked with a `$partition.xxx$` keyword map providing the fields that uniquely describe the partition being aggregated by the operation.

The account aggregation operations are designed to coexist. If the user runs a regular, non-partitioned account aggregation, the Account Aggregation operation is used. If the user selects to run a partitioned aggregation, which is specified by which Task and Task Options are selected in SailPoint, then the Partitioned Account Aggregation is used. The connector supports both modes simultaneously. Admins configuring Web Services connectors are encouraged to configure non-partitioned account aggregation before configuring a partitioned one. The connector logic places no restrictions or assumptions on the mode of operation; it freely supports non-partitioned, partitioned, or both at once.

The Partitioned Account Aggregation operation expects you to substitute one or more `$partition.xxx$` keyword tokens into the URL for the operation or a POST body delivered to the remote system. Continuing with the earlier example, imagine that you have a system that allows you to return only the accounts or account IDs that exist in a specific Cost Center. That GET request displays as follows:

```text
GET https://hr.acme.com/admin/listAccounts?costCenter=CC-AA

{
"idList": [
"3de42cd8-d0f6-4ff6-b683-e386b246e8da",
"73d3eacd-624e-4ca3-8b13-9095ccb9c8b3",
...
"67f8ab59-2923-422d-8772-c52cb4185723"
]
}
```

Configuring this in a Partitioned Account Aggregation is a matter of entering the `$partition.costCenter$` keyword into the URL as follows:

- **Context URL** - `/listAccounts?costCenter=$partition.costCenter$`
- **Method** - `GET`
- **Response - Root Path** - `$.idList.*`
- **Response - Schema Attribute** - `costCenter` Attribute Path: `$`
- **Response - Schema Attribute** - `name` Attribute Path: `$`

As with the non-partitioned Account Aggregation operation, the Partitioned Account Aggregation operation can be chained with child operations referring to it by name. In the examples above, the API only returns the ID property of the account record. A subsequent GET call must be made to retrieve the full account record. The child operation or sequence of operations that retrieve the full account must reference the Partitioned Account Aggregation.

### Multiple Partitioned Account Aggregation

You can use multiple Partitioned Account Aggregation operations. Like the Get Partitions operation, its use is intended to be strictly parent-child invocations. The behavior of multiple top-level peer Partitioned Account Aggregation operations is not recommended.

# Configuring Source Settings

## Aggregation Settings

Configure connector settings related to delta aggregation and partitioning in aggregation processes. Refer to [Partitioning Settings](<https://documentation.sailpoint.com/connectors/web_services/saas/help/partitioning.html#partitioning-settings>) for the partitioning settings.

### Delta Aggregation

Enable delta aggregation to configure the connector to only aggregate accounts which have had changes since the last aggregation process. This feature can help streamline aggregation processes.

> [!NOTE]
>
> **Screenshot**
>
> [![Delta Aggregation](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/delta_aggregation.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/delta_aggregation.png>)

1. Enable **Delta Aggregation** to aggregate accounts that have changed since the last execution.

   > **Note**
   >
   > Delta aggregation based on `account object type` is only applicable for managed systems that support the delta aggregation operation.
2. In the **Account Delete Status Attribute** field, enter an attribute value used to mark objects as deleted during delta aggregation processes. For example:

   `deleted=true`
3. Enter the **Date Format** to use for the date and time data sent for delta aggregation.
4. In the **Server Timezone** field, specify the timezone for the source's server.
5. Select **Save**.

## Common Configuration

1. In the **Connection Timeout (in seconds)** field, enter the connection timeout value in seconds.
2. The Web Services source supports client certificate authentication for the API endpoints with SSL. Enter the valid details in the **Client Certificate** and **Client Private Key** fields, respectively. Refer to [Converting a Private Key to RSA PEM Format](<#converting-a-private-key-to-rsa-pem-format>) for more information.
3. In the **Account Enable Status Attribute** field, enter the attribute name and value to set the account status while loading accounts. The status of accounts with the specified attribute and value is marked as enabled; the status for all other accounts is disabled. For example, if you enter `status=Active`, the status of all accounts with the `status` attribute set to `Active` is enabled.

   > **Note**
   >
   > The **Account Enable Status Attribute** field supports multiple values for status attribute. If you need to enter multiple values for the **Account Enable Status Attribute**, separate them by using a comma as displayed in the following example: `status=Active,Pending`
4. In the **Account Lock Status Attribute** field, provide the value required to check the account lock status. For example, if you enter `status=inactive`, the account schema `status` attribute determines whether the account is locked or not. In this case, all accounts with their `status` attribute set to inactive are considered locked by the connector, and therefore they are not included in provisioning.

   > **Note**
   >
   > The **Account Lock Status Attribute** field supports multiple values for the status attribute. If you need to enter multiple values for **Account Lock Status Attribute**, separate them by using a comma as displayed in the following example: `status=Locked,Inactive`
5. Select **Save**.

### Converting a Private Key to RSA PEM Format

The connector only supports the PEM format for the Client Certificate and the private key. Additionally, the Web Services connector expects the PEM private key to be an RSA PEM private key. The following process enables you to convert the private key to an RSA private key on a Windows computer:

1. Download and extract the latest version of openSSL.
2. Open **cmd** to the OpenSSL path.
3. Copy the **Private\_ADP\_Key.key** file to the extracted OpenSSL path.
4. Run the following command:

   ```text
   openssl rsa -in Private_ADP_Key.key -out rsa_private_key.pem
   ```
5. Use this **rsa\_private\_key.pem** file in the connector.

## Provisioning Settings

Configure settings related to provisioning operations.

> [!NOTE]
>
> **Screenshot**
>
> [![Additional Settings - Provisioning](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/additional_settings_provisioning.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/additional_settings_provisioning.png>)

The Web Services connector supports the following provisioning features:

- **Create Account With "Ent" Request** - The Create Account operation executes with entitlement attributes. If the Create Account operation response contains the required attributes, including the identity attribute, the account object is created and the account link displays under the identity from whom the account creation was triggered.
- **Update Attributes with Change Password** - Include a password change and an attribute change in a single request. The **Change Password** operation is used for changing the password on the managed system. If the provisioning plan contains no attribute request with the name "password", the update operation type endpoint is invoked. Enabling this attribute does not include requests for add or remove entitlement operations. Those requests are executed independently.
- **Add or Remove Entitlements in a Single Request** - Enable Add or Remove Entitlements in a Single Request to send multiple entitlement requests at once to the managed system as opposed to separately.
- **Skip getObject Call during Create Provisioning** - Enable Skip getObject Call during Create Provisioning to skip the getObject call during initial object creation in provisioning operations.
- **Get Object Required for Pass-Through Authentication** - The Pass-Through Authentication (PTA) operation is used to perform verification of user credentials. When selected, it executes the Get Object operation to verify if the entered username (considered an Account ID attribute) is present on the target system. When unselected, it skips the Get Object operation. The Pass-Through Authentication operation must have response mapping with account object schema attributes. Refer to [Pass-Through Authentication](<https://documentation.sailpoint.com/connectors/web_services/saas/help/configuring.html#pass-through-authentication>) for more information.

## Common Configurations for Errors

> [!NOTE]
>
> **Screenshot**
>
> [![Additional Settings - Common Configuration](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/additional_settings_common_config.png>)](<https://documentation.sailpoint.com/connectors/web_services/saas/help/img/additional_settings_common_config.png>)

### HTTP Errors

You can manually configure HTTP error codes and messages for times when an API endpoint in the Web Services source sends unexpected error codes to flag failure conditions. Manually configuring these codes enables the connector to properly handle them. Configure the source with all possible HTTP error codes and messages that the API endpoint may return. Enter the **HTTP Error Keys** and their respective **HTTP Error Values**.

> [!NOTE]
>
> This is not applicable to the child endpoints.

For example:

- The Web Services source returns the HTTP status code `200`, but the response payload contains an error. Without the manually entered HTTP error, the source won't know that it must fail the request.
- During OAuth token generation, the source needs to regenerate a token to replace an invalid or expired token. You can configure an HTTP error code or message to specify an invalid/expiry token error in this event. The source regenerates and saves the token for OAuth2 authentication, then retries the operation with the newly generated access token.

#### Object Not Found Error Messages

Enter the error message that the connector displays when it can't find objects or fails to make connections. For example:

```text
404 - Object Not Found
```

#### Disable Cookies

The Web Services source can disable cookies while executing HTTP requests. You can disable cookies for all the operations performed except for the authentication API.

Refer to [Support for Cookies](<https://documentation.sailpoint.com/connectors/web_services/saas/help/http_operations.html#support-for-cookies>) for more information.

# Troubleshooting

If you encounter any of the following issues or errors, SailPoint recommends that you follow the guidance provided below to resolve the error before contacting SailPoint Support.

For issues or errors that are not addressed in this connector guide, refer to the following resources for troubleshooting information:

- [SailPoint Identity Services Documentation](<https://documentation.sailpoint.com/saas/help/index.html>)
- [SailPoint Support Knowledge Base](<https://support.sailpoint.com/csm?id=kb_view2&amp;kb_id=05ff44289f011200550bf7b6077fcfa3>)
- [SailPoint Developer Community](<https://developer.sailpoint.com/>)

## Debug Logs

For information about managing additional source settings, including debug logging and downloading connector logs, refer to [Managing Additional Settings](<https://documentation.sailpoint.com/saas/help/sources/managing_additional_settings.html>).

## Create Account Operation Fails While Using Recommended Mappings in the Account Policy

The create account operation fails even though the recommended attribute mappings are used in the Account Policy.

**Resolution**: Ensure that the managed system is enabled to set the account attributes used by the Account Policy, then try the Create account operation again.

## Aggregation Continually Fails Due to Temporary Connectivity Issue

Account aggregation processes continually fail with each retry attempt the connector makes, as the connector assumes the issue is related to a connectivity error.

The error occurs when the connector is trying to aggregate a large amount of data and SailPoint times out before it receives a response from the managed system.

**Resolution**: Reduce the amount of data the connector has to aggregate at once:

1. Verify that the aggregation is successful with a smaller dataset. To do so, remove Pagination and run account aggregation with a smaller set of data.
2. If the data successfully aggregates, you can attempt to break up the large dataset into smaller pieces by reducing the value of the **Page Size** setting.

## ConnectorError: Missing Output When Disabling Accounts

When you attempt to disable an account, the process fails with an error message similar to the following example:

```text
There was an error trying to disable the account [ConnectorError] missing output (requestld: XXXXXXXXXXXXXXXXXXXXXX)
```

In certain configurations, this error may occur if the API returns a null response.

**Resolution**: Enable the `handleNullResponseInDisable` parameter in the source configuration via SailPoint's REST API.

```json
[
    {
        "op": "add",
        "path": "/connectorAttributes/handleNullResponseInDisable",
        "value": true
    }
]
```

> [!NOTE]
>
> Refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>) in the SailPoint Developer Community for more information on SailPoint's REST APIs.

## All Operations Fail Due to a Missing Cookie

Some managed systems require only a cookie for authentication.

**Resolution**: Do the following for each operation:

1. Create an endpoint API for cookie generation.
2. Create a second endpoint of the same type and configure an API to execute its required operation.

# Timeout Errors and Settings

Timeout errors might occur when SailPoint is waiting for a response from the connector-runtime. These errors are applicable to all connectors and tend to occur during the setup of sources or when sources are down.

This document is designed to give specific information that can be used to resolve these errors.

Each timeout attribute has a default time value that is listed in seconds or minutes. Increasing the time value may resolve the error as it will allow for longer communication time between the two systems, thus avoiding the timeout error.

To increase the communication time, increase the value of the appropriate timeout attribute. Then submit the change to the connector-runtime using the SailPoint REST API.

> [!NOTE]
>
> For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1/>) in the SailPoint Developer Community.

### aggregateTimeout

**Description:** This parameter is set for the aggregation timeout, measured in seconds.

**Resolution:** Increase the `aggregateTimeout` value gradually to optimize aggregation. Start with 180, then increase to 600, 900, and finally 1800. The maximum value is 3600 seconds.

For example:

If your current time value is 180 seconds, update the `aggregateTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/aggregateTimeout",
        "value": 600
    }
]
```

### healthCheckTimeout

**Description:** This parameter is set for the test connection and health check timeout.

**Resolution:** The default value is 30 seconds. If the timeout error continues, increase the value in 15 second increments and try again.

For example:

If your current time value is 30 seconds, update the `healthCheckTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/healthCheckTimeout",
        "value": 45
    }
]
```

### provisioningTimeout

**Description:** This parameter is set for provisioning timeout.

**Resolution:** Increase the `provisioningTimeout` value gradually to optimize provisioning. Start with 180, then increase to 360, and finally 600. The maximum value is 600 seconds.

For example:

If your current time value is 180 seconds, update the `provisioningTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/provisioningTimeout",
        "value": 360
    }
]
```

### timeout

**Description:** This parameter is set for pass-through authentication timeout.

**Resolution:** The default value is 15 seconds. If the timeout error continues, increase this value in 15 second increments and try again.

For example:

If your current time value is 15 seconds, update the `timeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/timeout",
        "value": 30
    }
]
```

### apiTimeout

**Description:** This parameter is set for API time tracking; customers can check it using an external tool.

**Resolution:** The default value is 60 seconds. If the error continues, increase the value by 15 second increments and try again.

For example:

If your current time value is 60 seconds, update the `apiTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/apiTimeout",
        "value": "75"
    }
]
```