cusersu6068964downloadsapirequestsc.zip@ziad.abourizk

Can you please confirm the API call you are making so that I can assist you?

I see you are trying to save a case (API call- SEQ-2c: Save a case: Individual) when using your C# code, but see you are calling the API request -"SEQ-4a: Screen a case" in the Postman console.

As this is your first attempt, I would like to state that ideally the users start with a GET request to make sure the HMAC generation is correct and then move on to the complex POST requests.

I am attaching few sample code requests in C# (also available in the download section of the developer community) for your reference.

Attachment has one get request and one post request sample code.

Kindly note the code sample provided is to just guide the developers on how to generate successful requests and expect our clients to design their own code to suit their use case.

@ziad.abourizk ,

I see the postman code shared is for the API call "SEQ-1b: Get a specific group by ID" while the C# data to sign value, c# HMAC and c# authorisation is for the API call "SEQ-2c: Save a case: Individual", so the HMAC signature for both the API calls will always be different.

That being said, I will try provide reason why the clients get 401 response code for the API call "SEQ-2c: Save a case: Individual" (POST).

Generally the users encounter 401 for the below reasons:

Incorrect data to sign value: This seems to be perfect and in correct format as per the example shared by you.

Authorisation: This is correct too.

HMAC signature: This seems to be incorrect as I used your account credentials to call the "SEQ-2c: Save a case: Individual" and see that the HMAC is different. The content length your code is calculating for the payload you are sending in your request seems to be incorrect too. Your code should be able to calculate the content length correctly to avoid the 401 unauthorized issue.

There can be two reasons why are you getting an incorrect HMAC:

1. Your code is generating an incorrect HMAC-BASE64 signature even though the data to sign value and the API secret being provided to the HMAC-BASE 64 function is correct.

2. The content length your code is calculating for the payload is incorrect which is leading to incorrect HMAC signature.

Can you please confirm if you are successfully able to make any GET request using your code? Has your HMAC worked for any of the requests till now?

Can you compare the content length being generated using your code and by postman and see if they are the same? For this make share you are using the same payload with exact spaces and characters in both postman and your code. If you see there is a difference in the content in both cases, this must be the reason for 401.

You can use the below code to calculate the content length in your code.

string postData = "{\"secondaryFields\":[],\"entityType\":\"INDIVIDUAL\",\"customFields\":[],\"groupId\":\"XXXXXXXXXXXXX\",\"providerTypes\":[\"WATCHLIST\"],\"name\":\"乔治布什\"}";
            //Console.WriteLine(postData.Length);
            string msg = postData; 
            //Console.WriteLine(msg);
            UTF8Encoding encoding = new UTF8Encoding();
            byte[] byte1 = encoding.GetBytes(postData);


WebReq.ContentLength = byte1.Length;

Please use byte1.Length in the data to sign variable for the value of content length.

@ziad.abourizk

Kindly note for screening request API, we do not expect content length and content type to be sent in the authorization headers and in the data to sign variable, even though it is a POST request.

Data to sign variable should give the output in the below format:

(request-target): post /v1/cases/{ {case-system-id}}/screeningRequest
host: rms-world-check-one-api-pilot.thomsonreuters.com
date: Sun, 12 Aug 2018 07:51:57 GMT

Please note { {case-system-id}} here should be replaced by the case system Id that was received in the JSON response when the API call "Save a case".

Authorization should be in the below format:

Signature keyId="XXXXXXXXXX",algorithm="hmac-sha256",headers="(request-target) host date",signature="DiInIutjPgjQ2eeKs7GPKQzrmxl57n15ah5ghEu1oik="

Also, the URL should be:

https://rms-world-check-one-api-pilot.thomsonreuters.com/v1/cases/{ {case-system-id}}/screeningRequest

Here again the { {case-system-id}} should be replace by the case -system-id

So assuming { {case-system-id}} = 0a3687d0-6334-14b4-98d0-eab00000694d

The data to sign value should be:

(request-target): post /v1/cases/0a3687d0-6334-14b4-98d0-eab00000694d/screeningRequest
host: rms-world-check-one-api-pilot.thomsonreuters.com
date: Sun, 12 Aug 2018 07:51:57 GMT

The URL should be:

"https://rms-world-check-one-api-pilot.thomsonreuters.com/v1/cases/0a3687d0-6334-14b4-98d0-eab00000694d/screeningRequest

Also, you can always compare the kind of data to sign variable and the authorization header you have to send for each API call using the "code" section of Postman or the pre request script of Postman.

Kindly let me know if you need further clarification on this.

@ziad.abourizk

Please find the sequence of API calls in order to screen a case successfully and view the matches of the case below.

1. SEQ-1a: Get my top-level groups: This API call provides you the list of group Id available in your account.

2. SEQ-1c: Get the case template for a group: This API call provides the custom fields and secondary fields which can be used in step 3 to save a case.

3. SEQ-2c: Save a case: Individual: This API call saves the case with the payload/body sent in the request and returns a JSON response with the case -system-id. This call creates an entry but does not screen the case. The case-system-id is a unique identifier for each case generated by the system so that you can use it perform operations on it at a later stage.

4. SEQ-4a: Screen a case: Use the case-system-id obtained in step 3 to screen a case by calling this API.

5. SEQ-8: Retrieve the audit log for a case: Use the case-system-id to find out if the case has been screened or not by calling this API. To know more about audit API. Please refer to the link below:

https://community.developers.refinitiv.com/questions/26633/statuscode-1.html

5. SEQ-5b: Get screening results: If the case has been screened, use this API to get the list of all the matches populated due to screening the case. You have the case-system-id to pull the results of the associated case. It should be the same case-system-id that was returned when the case was saved in step 3.

6. SEQ-5c: Get a World-Check profile: Use the attribute ''referenceId' returned in the JSON response of step 5 to pull the entire world check profile of the match to identify if the match is a false positive, hit/no hit, etc.

You can also refer to the link below for more detailed info on how to screen cases using the API.

https://developers.refinitiv.com/en/api-catalog/customer-and-third-party-screening/world-check-one-api/quick-start#world-check-one-api-sync-screening-steps-v-1

The above steps are used to screen cases asynchronously and the above sequence has to be followed.

This was to help you give you an idea of how screening is performed using the API. Let me answer your questions in the next answer I post.

@ziad.abourizk

Please find the answer to your questions below:

So for each screening request, I should get the case Id first using the Save a Case API request, right ?

[Ans by Irfan]: Yes, you have save the case first to obtain a case-system-Id and then use the case-system-Id to screen the case or obtain the results after screening the case. Lets think of a case-system-id as an unique identifier that identifies each case that you save uniquely and refer them at a later point of time using the same case-system-Id.

In my application I have to scan customers and organization. So for each one, I will create an API request for "Save A Case", then "Screen Case".

[Ans by Irfan]: Yes, you have to create a new case for each entity name (individual/organization) and screen them after the case has been saved.

And can I reuse the case id for the next screen request? I mean I will get a case id and I use it on screening, and for the next screening I can use the same case id or I need to call the save a case again?

[Ans by Irfan]: Are you trying to re screen the same case again and do not want to create a new case? If yes, then you can use the case-system-Id. If you are trying to screen a new entity name, then you have to save that case which will give a new case-system-Id and then screen the case using the obtained case-system-id.

Also do you have any API which I can pass multiple case id and get results.

[Ans by Irfan]: Kindly note "Screening result" API uses the case-system-id and not the case-id to fetch the results of a case. No, we do have an API to get results for multiple case-system-ids.

@ziad.abourizk,

URLhttps://rms-world-check-one-api-pilot.thomsonreuters.com/v1/cases/0a3687d0-6334-14b4-98d0-eab00000694d/screeningRequest

(request-target): post /v1/cases/0a3687d0-6334-14b4-98d0-eab00000694d/screeningRequest
host: rms-world-check-one-api-pilot.thomsonreuters.com
date: Mon, 13 Aug 2018 18:06:13 GMT
{"secondaryFields":[],"entityType":"INDIVIDUAL","customFields":[],"groupId":"0a3687d0-64a6-1d01-9945-119200000daf","providerTypes":["WATCHLIST"],"name":"Bashar"}

HMACqrw1bRpP1ZWrZ4wyIxNhlDdgaz7mQeI8D5oaFQU1Tzw=

headers=\"(request-target) host date\",

As reported by you, I see you are sending the above parameters in your request to screen a case.

Please note this POST request does not need a payload so you should not be using the below payload/body at all. This information has already been given to us when you saved the case with the same payload.

{"secondaryFields":[],"entityType":"INDIVIDUAL","customFields":[],"groupId":"0a3687d0-64a6-1d01-9945-119200000daf","providerTypes":["WATCHLIST"],"name":"Bashar"}

So your data to sign value should be

(request-target): post /v1/cases/0a3687d0-6334-14b4-98d0-eab00000694d/screeningRequest
host: rms-world-check-one-api-pilot.thomsonreuters.com
date: Sun, 12 Aug 2018 07:51:57 GMT

The authorization should be in the below format.

Signature keyId="XXXXXXXXXX",algorithm="hmac-sha256",headers="(request-target) host date",signature="DiInIutjPgjQ2eeKs7GPKQzrmxl57n15ah5ghEu1oik="

Kindly note you should be using the case-system-Id that was obtained when saving the case. The case-system-Id: 0a3687d0-6334-14b4-98d0-eab00000694d that I am using is just for an example and you should be using the case-system-Id associated to your case to get the correct result.

Case-system-Id are unique for each case and for each group and for each account, so always use the correct case-system-Id associated to your case, belonging to your group and account to screen the case.