ISD endpoint

Query Remaps:

$area query is remapped to $area:like
$area:like query is slower than the $area query but queries can disregard split regions.
example: In an $area:like query 49505 will return 49505 And 49505-Kent


Specific $table.field query is remapped to $and query:
Only $table.field in the exact format below are remapped

query format remapped:
{"$table.field":[{"mi_bridges_id_matches.site_id__c": [...]},{"mi_bridges_id_matches.agency_id__c": [...]}]}

remapped to: {$and:[{location_id: [...]},{organization_id: [...]}]}


ID Remaps:

$in remapping
Query of exact type to be remapped:
{"id" : {"$in" : ["number1", "number2", ...]}}

Remapping works as follows:
First endpoint will search the mi_bridges_id_matches table to find any external_id__c (aka ServiceSite_Id) ids that match a provided number.

If a match is found then the id will be remapped to the OR id that corresponds with the external_id__c found. This allows the client to use historical ids and relate them to OR ids.

Also when a mapping is found the API will return the mi_bridges (visionlink ) data for reference.

As an example if client queries {"id":{"$in":[5]}}
This will be remapped to {"id":{"$in":[4]}} and below object will return in the api:
Api response:

$and remapping

Query to be remapped:
NOTE: Client can have one, all or any combination of the id types: organization_id, location_id, id
NOTE: order of id names does not matter
NOTE: order numbers within arrays does not matter
NOTE: ids will be remapped if distance_info is included or not
{"$and": [{"organization_id": ["number", "number", ...]}, {"location_id": ["number", "number", ...]}, {"id":["number", "number", ...]}]}

$and query also allows for distance_info
{"$and": [{"distance_info": {"type":"value","name":"value"}},{"organization_id": ["number", "number", ...]}, {"location_id": ["number", "number", ...]}, {"id":["number", "number", ...]}]}

Remapping works as follows:
Endpoint will search the mi_bridges_id_matches table to find visionlink resources that match each type of the ids provided. Either all of the ids in a resource hierarchy are remapped or none of the ids in the resource hierarchy are remapped.

example - remapping found:
query: {"$and": [{"organization_id": [3789]}, {"location_id":[3219]},{"id":[5]}]}
There is a visionlink resource with Agency_Id = 3789 Site_Id = 3219 and ServiceSite_Id = 5
A complete resource hierarchy was found therefor all ids will be remapped to:
{"$and": [{"organization_id": [971]}, {"location_id":[972]},{"id":[4]}]}

example - one remapping found:
query: {"$and": [{"organization_id": [111, 3789 ]}, {"location_id":[3219, 222]},{"id":[333, 5]}]}
There is a visionlink resource with Agency_Id = 3789 Site_Id = 3219 and ServiceSite_Id = 5
There is no a visionlink resource with any other combination of Agency, Site and Service ids.
A complete resource hierarchy was found and will be remapped. The remaining ids will be unchanged.
Actual query the api executes is below.
{"$and": [{"organization_id": [971, 111]}, {"location_id":[972, 222]},{"id":[4,333]}]}

example - remapping NOT found:
query: {"$and": [{"organization_id": [3789]}, {"location_id":[3219]},{"id":[2]}]}
There is no visionlink with Agency_Id = 3789 Site_Id = 3219 and ServiceSite_Id = 3
Therefor no ids will be remapped. This allows new resources to return that are not referenced in visionlink data.

Field remaps and additions:
Under the phones joined table the number field is remapped to phone_number
Under the locations joined table the email field is added
Under the physical_address joined table the confidential field is added