Ideally when you screen an entity you get X number of matches and our customers usually fetch the profiles of all the matches obtained in the result, for example: let’s say you screened John Smith and you obtained 90 matches against it in which 30 are strong/medium matches and 40 are weak matches and 20 are auto-resolved matches which can be ignored so consuming the “Get Profile API” for all the 90 matches would not only potentially cause unnecessary load on the World-Check Platform but also slow down the turnaround time on the customer end which is not at all efficient.
Best Practice Approach:
To overcome this, we recommend our customers to follow a set of best practices laid down to make the best use of our product which will help you build your integration in the most efficient manner.
what we recommend here is that when you place a screening request from your system and receive a list of matches in the response back from World-Check One, the profile API must be called only when the user clicks on the potential match on their surface and not for every match returned in the response, this way we avoid the large response time on the client’s system and also unnecessary potential load on our platform.
An important point to note here is that you can easily ignore the Auto-resolved matches while fetching the profiles as highlighted in the above scenario, out of the 90 matches 20 are auto-resolved so you can build logic in place at your end to ignore these 20 matches and then fetch profiles of the potential matches on trigger i.e. when a user clicks on any of the potential matches "Fetch World-Check Profile" API can be consumed for that particular match.
Suppose, John Smith has 230 matches, fetching 230 profiles is just inefficient way of consuming the Get Profile API, we must ensure the profile details are fetched only for the potential matches in interest and not for all the matches.