Hi @frederic.gaillard,

Thank you for your response.

To reduce the amount of API calls you can implement the following:

So if the caseSystemId does not exist in your database you do these steps:

- saveAndScreen -> SEQ-case-save-and-screen-cases: Save and screen multiple cases

And save the caseSystemId for later use, then when needed:

- screeningStatus (see lastScreenedDate with 200 OK response) -> SEQ-case-screening-statuses: Retrieve screening status for multiple cases

If you have the caseSystemId in your database you do these steps:

The caseSystemId that have been saved already, then when needed:

- screeningStatus (see lastScreenedDate with 200 OK response) -> SEQ-case-screening-statuses: Retrieve screening status for multiple cases. So, there is no need to call any API endpoint between saveAndScreen and screeningStatus once caseSystemId has been stored in your database.

Please bear in mind that saveAndScreen -> SEQ-case-save-and-screen-cases: Save and screen multiple cases is to create a new cases. You do not have to create new cases with saveAndScreen for an already existing data you are sending to our end. For example you do not have to, each time, create a new saveAndScreen with the exact name: Clark Kent, caseId: Superman, name: Bruce Wayne, caseId: Batman. You create these names (saveandScreen) once and then check later with screeningStatus.

Unless, for some reason some variables need to change with these names (maybe add/remove date of birth), then only you make use of another API endpoint that fit your business needs. The caseSystemId does not change.

Best regards,

Virgill

Hi @frederic.gaillard,

Thank you for reaching out to us.

The API endpoint "cases/{caseSystemId}/screeningRequest" is an asynchronous operation, it returns a 201 Created immediately meaning Screening request successfully queued for asynchronous processing.

As a result of this call, the screening request will be queued to be processed. When this request has been processed, there will be a new SCREENED_CASE audit event that can be queried via /cases/{caseSystemId}/auditEvents .Then only can the results be retrieved via /cases/{caseSystemId}/results.

Please feel free to reach out if you have any further questions.

Best regards,

Virgill

Hi @virgill.pinas ,

Here's one of the results from the auditEvents response:

{
  
    "id": "5jb6me9g89741gr46bgsofud9",
    "objectId": "5jb8e4ydbsg01gr468c3ccjhr",
    "eventDate": "2022-06-17T07:46:39.514Z",
    "actionedByUserId": "c1ec030e-8f4c-4c07-bf51-181f9a961ff6",
    "actionedByUserName": "Someone",
    "note": null,
    "entityType": "CASE",
    "actionType": "SCREENED_CASE",
    "auditEventToDate": null,
    "details": {
  
        "detailsType": "ScreenCaseAuditDetails",
        "userId": null,
        "statusCode": "COMPLETED",
        "screeningState": "INITIAL",
        "noOfNewResults": 0,
        "noOfReviewRequiredResults": 0,
        "noOfExcludedResults": 0,
        "noOfAutoResolvedResults": 0,
        "providerTypes": [
            "WATCHLIST"
        ],
        "caseScreenRequestor": null,
        "caseSystemId": "5jb8e4ydbsg01gr468c3ccjhr"
    }
}

If I understood correctly if the action is SCREENED_CASE it means the screeningRequest has been completed?

There are no other properties I have to check to proceed to the next call? Like statusCode

Another thing, when I try to get the results after the auditEvents is completed, I get an error 401 Unauthorize.

Hi @frederic.gaillard,

Thank you for your response:

I can advise on the following:

If I understood correctly if the action is SCREENED_CASE it means the screeningRequest has been completed? => When the API endpoint "cases/saveAndScreen" is called, it does not mean that the screeningRequest has been completed because saveAndScreen happens asynchronous. (Wait 2 to 5 minutes before making the following endpoint) So, when the new case with API endpoint "cases/saveAndScreen" has been processed by our platform, you can query this processed case via the endpoint auditEvents and then view the "results".

There are no other properties I have to check to proceed to the next call? Like statusCode => A response 200 OK should be expected.

Another thing, when I try to get the results after the auditEvents is completed, I get an error 401 Unauthorize. => This error code could indicate that the URL API endpoint "results" was modified or body contained data. The endpoint "results" body should not contain any data.

I have added the following steps to assist if with your business logic it is mandatory to apply these API calls:

- saveAndScreen -> SEQ-case-save-and-screen-cases: Save and screen multiple cases

- screeningRequest(drop this endpoint, it is redundant for your use case) -> SEQ-screen-sync-simple: Perform Synchronous Screening: Simple

- auditEvents -> SEQ-case-audit: Retrieve the audit log for a case

- results -> SEQ-case-investigate-results: Get screening results

If your business logic does not really require the above 4 steps, then you can implement only the following 2 steps.

- saveAndScreen -> SEQ-case-save-and-screen-cases: Save and screen multiple cases

- screeningStatus (see lastScreenedDate with 200 OK response) -> SEQ-case-screening-statuses: Retrieve screening status for multiple cases

Best regards,

Virgill

Hi @virgill.pinas,

So if the caseSystemId does not exist in our database we do these steps:

- saveAndScreen -> SEQ-case-save-and-screen-cases: Save and screen multiple cases

- screeningStatus (see lastScreenedDate with 200 OK response) -> SEQ-case-screening-statuses: Retrieve screening status for multiple cases

And save the caseSystemId for later use.

If we have the caseSystemId in our database we do these steps:

- saveAndScreen -> SEQ-case-save-and-screen-cases: Save and screen multiple cases

- auditEvents -> SEQ-case-audit: Retrieve the audit log for a case

- results -> SEQ-case-investigate-results: Get screening results

If we implement this, will it reduce the cost of calling the APIs?

Which one of these calls is billed?

Because the objective is to reduce the cost by re-using the results of cases we already screened.

Regards

Hi @virgill.pinas,

This is working like a charm, thanks ^^

How should I handle the case where we have the casesSystemId in our database but it does not exist anymore in yours? Same question if we send 2 casesSystemIds but only one returns with a result and the second does not exists anymore.

I should do a saveAndScreen but what is the error or HttpStatusCode returned by screeningStatus?

Regards

Hi frederic.gaillard,

Thank you for reaching out. Happy to be of service!

Kindly note that World-Check One Platform does not perform "house cleaning" on caseSystemIds. We do not delete caseSystemIds nor do our CasesystemIds expire.

If a casesSystemId does not exist on our end, try for example requesting a summary of cases based on date range(query) -> SEQ-user-activity-monitoring-initial: User Activity Monitoring. This way you will have an better overview of all your cases.

If you send 2 caseSystemIds and only one "came back" with a result, then try above API endpoint.

Please feel free to explore our API reference guide for further information;

https://developers.refinitiv.com/content/dam/devportal/en_us/product-docs/wc1-api/documentation/v2/schema-reference/wc1-api-schema-reference-documentation.html

Best regards,

Virgill

Perfect then, thanks for your help ^^