I’ve only done a few integrations using web services and have run into a situation that I haven’t been able to find a solution to. I saw one similar post here, but it was closed with no solution. All the other posts about multiple endpoints seem to be about getting the base list of users from one endpoint, then using a child one to gather additional attributes.
In my case, the /employees
endpoint provided must be called with a filter, meaning there is no way to return all users in the first call. I’ve confirmed this API limitation with the company.
Here are the methods Ive tried. (in dropdowns for clarity)
Method # 1
-
Account Aggregation - 1 - Locations
- GET
/locations/
- Root Path
$.records[*]
- JSON records array contains 90 location objects.
- Response Mapping
locationId -> locationId
locationId
is in the account schema.
- GET
-
Account Aggregation - 2 - People
- GET
/employees?locationId=$response.locationId$
- Root Path
$.records[*]
- The employees are always returned in an array, even if there is only one at that location.
- Response Mapping
employeeExternalId -> employeeExternalId
etc.- There are 16 JSON attributes mapped to the account schema. They are named in ISC the same way they are named in the JSON objects for simplicity.
- Parent Endpoint
Account Aggregation - 1 - Locations
- GET
Method # 2
-
Account Aggregation - 1 - Locations
- GET
/locations/
- Root Path
$.records[*]
- JSON records array contains 90 location objects.
- Response Mapping
locationId -> locationId
locationId
is in the account schema.
- GET
-
Account Aggregation - 2 - Office
- GET
/employees?locationId=$response.locationId$
- Root Path
$.records[*]
- JSON
records
array contains an object for each employee.
- JSON
- Response Mapping
employeeId -> employeeId
employeeId
is in the account schema.
- Parent Endpoint
Account Aggregation - 1 - Locations
- GET
-
Account Aggregation - 3 - People
- GET
/employees?employeeId=$response.employeeId$
- Root Path
$.records[*]
- This call always returns the single employee in the
records
array.
- This call always returns the single employee in the
- Response Mapping
employeeExternalId -> employeeExternalId
etc.- There are 16 JSON attributes mapped to the account schema. They are named in ISC the same way they are named in the JSON objects for simplicity.
- Parent Endpoint
Account Aggregation - 2 - Office
- GET
Note: In method 2 I’ve tried making the type of the 3rd ‘people’ step both an ‘account aggregation’, and ‘get object’ http opertaion.
Both methods end up with the same number of ‘accounts’ as there are locations. In other words, if a location had just one employee it shows correctly in the account list, but the locations that return multiple employees all get merged into a single account.
I’ve examined bidirectional API captures of each method, and in each case I see all the steps (2 or 3) in each method being called, and the expected data is returned from the API.
It just seem like no matter what I do, that first step expects to collect all possible employee records, and child steps can only add information to that initial set.
TL;DR
I need to make multiple dynamic calls to the /employees
endpoint and join them to get a complete list of accounts for this application.
/employees?locationId=1
{
"records": [
{ "Name": "Sam" },
{ "Name": "Mark" },
{ "Name": "Sally" }
]
}
/employees?locationId=2
{
"records": [
{ "Name": "Mary" }
]
}
/employees?locationId=3
{
"records": [
{ "Name": "Roger" },
{ "Name": "Alice" }
]
}
ISC Source Account Result:
Alice
Mark
Mary
Roger
Sally
Sam