Web Services Connector Help (EverBridge) - Basics

acrumley · February 18, 2026, 6:58pm

Which IIQ version are you inquiring about?

8.4p2

Share all details about your problem, including any error messages you may have received.

I’ve been trying to figure a solution on how to connect IdentityIQ to the EverBridge application. No OOTB connector, no SCIM api, and the vendor explicitly states that SSO (single-sign-on) does not provision accounts upon successful login.

Here is sailpoints docs on the connector: EverBridge Connector - Compass

From what I have gathered, this effectively leaves the Web Services Connector. I’ve been reading the documentation, and I have felt overwhelmed.
Integrating SailPoint with Web Services

The variable syntax is different than BeanShell or Apache Velocity. For anyone who has had to make a general web services connector to create and delete accounts, could you attach your XML template so I can see how to properly organize the API calls for provisioning actions?

I understand REST API very well because I am a web app developer. The difficulty for me is fitting what I know to do with REST APIs into IdentityIQ’s web service connector format.

Thanks,
Alex

trettkowski · February 18, 2026, 8:07pm

Hi @acrumley

Looking at the docs you provided, it definitely looks like the web services connector in IIQ should work.

Can you let us know what step you are stuck with? If you haven’t started, I would start with filling out the authentication method and adding a Test Connection Operation. Once authentication and test connection are working, the rest of the operations become more straight forward especially if you are familiar with beanshell in before/after rules.

Feel free to ask any questions so we can get you going!

Peddapolu · February 18, 2026, 11:40pm

Hi @acrumley ,

You can go ahead with the web service connector. The good thing is that you have the API document to implement this application without issues. Just follow the request body JSON and response JSON to aggregate accounts. I think you mostly don’t need Benshell code.

Sample Create account curl command.

curl --request POST
–url https://api.everbridge.net/rest/users
–header ‘accept: application/json’
–header ‘content-type: application/json’
–data ’
{
“firstName”: “example”,
“lastName”: “example”,
“email”: “example@everbridge.com”,
“secondaryEmail”: “example2@everbridge.com”,
“timeZoneId”: “America/New_York”,
“ssoUserId”: "exampleSsoId ",
“middlename”: “example”,
“suffix”: “example”,
“roleIds”: [
1503449006997507,
1814748236611731
],
“defaultRoleId”: 1814748236611731,
“contactId”: 1814748236611732,
“contactOrgId”: 1814748236611733,
“autoProvisionForEBU”: false,
“apiAccess”: true,
“flowDesignerOrgs”: [
“111, 222, 333”
]
}
’

I hope it works!

Thanks,

PVR.

neel193 · February 19, 2026, 7:23am

@acrumley Good part is you already have the documentations for both connector and EverBridge APIs. Please let us know where exactly you are stuck? Do you need any help with configuring the endpoints, mapping schema or something else. This will allow us to help you better.

acrumley · February 23, 2026, 2:11pm

Thank you for the help @neel193. I will more precisely define my hang-up. I read some more of the documentation on how to properly access objects within the Body/Response sections.

I need help with getting identity attributes pushed to the JSON body to define user creation. I need help with reading the object from the JSON response and mapping them to the schema for Links.

As for testing, I am not able to hit the API yet. However, I do know my timeline will be tight between initial tenant setup and go-live. I really don’t want to be scrambling trying to get this to work.

I am very good at extrapolating from example code, so if you have a web services connector that has similar REST endpoints for user management, I can easily read from where you get your data from syntax wise.

I’ve already done a little bit of homework for the basic user endpoints to help you see where I stand:

List Users:
Assuming JSON like

{
count: 40
users: [
[ firstName: “john”, lastName: “doe”]
….

]
paging elements …

}

Then for CREATE user: POST /rest/users

Body:

{
    "email": "$plan.identity.mail$",
    "firstName": "$plan.identity.firstName$",
    "lastName": "$plan.identity.lastName$"
}

then for DELETE user: DELETE /rest/users/#$plan.link.getName()$#
Body:


{
"id": "$plan.link.getName()$"
}

neel193 · February 24, 2026, 8:32am

@acrumley I don’t have any webservice app in my sandbox which i can share. But if it works, we can connect over a call to discuss and try out the configuration.

robert-hails · February 24, 2026, 1:03pm

The body for your create and delete requests looks like they should be updated

The goal with this body is to transform the attribute request info from the provisioning plan into the payload format that the API expects

Based on your use cases, would update to the following:

CREATE user: POST /rest/users

{
    "email": "$plan.email$",
    "firstName": "$plan.firstName$",
    "lastName": "$plan.lastName$"
}

The connector checks for email / firstName / lastName in the attribute request and updates the body after it is found.

You can populate these values using a Create Account Provisioning Form on your application

Likewise for your delete request:

DELETE user: DELETE /rest/users/#$plan.link.getName()$#

{
    "id": "$plan.id$"
}

More info can be found here in the SailPoint connector docs: Supported Operations

Peddapolu · February 24, 2026, 2:19pm

Hi @acrumley ,

First setp, you need to feed the values into the Provisioning Plan by using a provisioning policy: firstname, lastname, and id. Then, you can extract them from the provisioning plan in the request body. As said, you can’t get the identity object { "$plan.identity.mail$ directly from the provisioning plan. For this scenario, it’s better to create a provision policy, feeding the values by extracting them from the identity so that you will get the desired values in the Provisioning Plan. Then, the JSON values below will be set while the user requests access.

{
“email”: “$plan.email$”,
“firstName”: “$plan.firstName$”,
“id”: “$plan.employeeId$”,
“lastName”: “$plan.lastName$”,
“userName”: “$plan.fullName$”
}

provisioning policy :

Create account operation request body:

I hope it should work!.

Thanks,

PVR,

acrumley · March 9, 2026, 11:16am

Your snippet helps me be sure of the syntax for using existing link attributes in the URL bar to do any kind of account-based action (update attributes, delete specific account, etc.)

acrumley · March 9, 2026, 11:17am

Thank you for confirming on how to correctly populate data for the POST request, and how to correctly define that data.

Peddapolu · March 9, 2026, 4:36pm

@acrumley,

It is better to use the Provision policy if you need to calculate data and return retrun a value attribute; that’s why you can avoid the most complex things in the JSON body.

Thanks,

PVR.

acrumley · March 9, 2026, 5:12pm

Couldn’t agree with you more. Thank you for helping me organize where the logic goes and how to properly plug it into the Web Services connector API calls

Peddapolu · March 9, 2026, 5:27pm

Thank you @acrumley ,If I can help out, I will, if you have any further questions, feel free to ask the community.

Thanks,

PVR.

acrumley · March 19, 2026, 3:46pm

@Peddapolu Currently, i am able to query the users endpoint and get some data. However, the preview data button shows IIQ shoving all of the users records onto one row:

username = [“user1”, “user2”]

email = [“email1”, “email2”]

So then it only sees 1 account on the preview window and doesn’t iterate through them properly

Here is my List Uses (account aggregation) snippet:

API response format:

{
  "message": "OK",
  "firstPageUri": "https://api.everbridge.net/rest/users?roleId=0&pageSize=10&columnName=firstName&pageNumber=1",
  "nextPageUri": "https://api.everbridge.net/rest/users?roleId=0&pageSize=10&columnName=firstName&pageNumber=2",
  "lastPageUri": "https://api.everbridge.net/rest/users?roleId=0&pageSize=10&columnName=firstName&pageNumber=4",
  "page": {
    "pageSize": 10,
    "start": 0,
    "data": [
      {
        "id": 2289363974165,
        "firstName": "John",
        "lastName": "Doe",
        "userName": "jdoe",
        "ssoUserId": "jdoe1",
        "email": "john.doe@y12nsc.doe.gov",
        "timeZoneId": "America/New_York"
      }
    ],
    "totalCount": 39,
    "totalPageCount": 4,
    "currentPageNo": 1
  }
}

How would I do the pagination too? Thanks

trettkowski · March 19, 2026, 4:13pm

Hi @acrumley

Try updating your Root Path to $.page.data[*] then in your Attribute Path section, just reference the individual attribute like firstName.

Here is more info on paging, it looks like you can simply set your URL to the nextPageUri value which is provided in your response.

acrumley · March 19, 2026, 4:29pm

Yep, I was able to separate them out properly. thank you. I have read the pagination documentation thoroughly. However, i am not seeing in the pagination steps where I can overwrite the next URL for pagination calls.

I don’t hit pagination api’s often, and I’ve seen them different ways. I’m seeing my condition being:

TERMINATE IF nextPageUri == NULL

However, I don’t know in the URL bar on the original request how to update it accordingly for subsequent calls

trettkowski · March 19, 2026, 4:33pm

You can update the URL in the paging steps like so:

TERMINATE_IF $response.nextPageUri$ == null
$endpoint.fullUrl$ = $response.nextPageUri$

Peddapolu · March 22, 2026, 6:13pm

Hi @acrumley Yep, as per configuration, the connector behavior is good. I got it, since you are using a single data list object, it will come in a single row with all the user’s info. To fix this issue, you should configure the root path as $.page.data.* or $.page.data[*] in order to extract user data individually. I have provided a sample pagination logic, you can configure pagination based on your endpoint.

Pagination: I’ve hardcoded the limit values, since you have the endpoint, you can get them dynamically.

$limit$ = 5
TERMINATE_IF $RECORDS_COUNT$ < $limit$
$offset$ = $offset$ + $limit$
$endpoint.fullUrl$ = $application.baseUrl$ +“TrakkService/trakkUser?limit=”+$limit$+“&offset=”+$offset$

Thanks,

PVR.

acrumley · March 23, 2026, 7:24pm

I have successfully gotten the CREATE operation to work. However, DELETE is not. It says in the docs that the URL query parameters is enough to delete the account. I have made the correct request, but I am getting an error saying I don’t have the “Get-Object” option configured. From my understanding, I didn’t need this configured to do the DELETE operation:

I have the schema setup where the nativeIdentity is the unique ID that the application returns upon creation:

And I reference it like this in my DELETE request:

Topic		Replies	Views
The Web services connector create account IIQ Discussion and Questions webservice-connector , identityiq , accounts	29	648	March 1, 2025
Unable to access Identity from WebServices Connector After Rule IIQ Discussion and Questions webservice-connector , rules , identityiq , provisioning	32	1920	October 24, 2023
Webservice connector in iiq IIQ Discussion and Questions webservice-connector , identityiq	5	50	May 6, 2026
Web Service not Passing variable IIQ Discussion and Questions webservice-connector , identityiq , access-requests	30	1962	December 16, 2023
IdentityIQ Web Services Unauthorized, HTTP Error Code: 401 IIQ Discussion and Questions webservice-connector , identityiq , provisioning , access-requests , connectors	17	329	July 5, 2025

Web Services Connector Help (EverBridge) - Basics

Which IIQ version are you inquiring about?

Share all details about your problem, including any error messages you may have received.

Related topics