Intermittent 400 Bad Request error for the same screening data
When performing a synchronous screening against the /v1/cases/screeningRequest endpoint on the Pilot environment for World Check One we are experiencing an intermittent error from the API.
Sometimes we will get a 400 Bad Request error (with nothing else in the response body so no indications of what might have gone wrong) and sometimes it will succeed using the identical data in the request json.
This has been tested using the "Thomson Reuters World-Check One API v1.5" Postman Collection as well as in a C# implementation with the same occasional failure behavior seen in both.
Example Request Body:
{
"groupId": "{OUR_GROUP_ID}",
"entityType": "INDIVIDUAL",
"caseId": "LOCAL_TEST_448eaadd-58cd-46df-9db7-4167572231af_2",
"name": "Влади́мир Влади́мирович Пу́тин",
"providerTypes": [
"WATCHLIST",
"CLIENT_WATCHLIST"
],
"customFields": [
{
"value": "92374a3a-dc1d-4d02-be83-59c82d9d95f0",
"typeId": "0a3687cf-6c8f-1233-9b2c-ccb700000630"
}
],
"secondaryFields": [
{
"value": "MALE",
"typeId": "SFCT_1"
},
{
"value": "RUS",
"typeId": "SFCT_3"
},
{
"value": "RUS",
"typeId": "SFCT_4"
},
{
"value": "RUS",
"typeId": "SFCT_5"
}
]
}
I can send this and have it fail with a 400 Bad Request. If I just try sending it again, changing nothing about the request body, it will succeed the second or third time it gets sent.
What is the cause of this inconsistency and how should we be interpreting the 400 Bad Requests?
Any help is appreciated.
Thank you
Let us do a live test to determine the reason for this.
Will you be available for a call on Monday. Let me send you a webex invite to your email address so that we can connect to test and fix this.
Can you please provide us the request headers and response headers from Postman Console both for the failed request and the successful request?
You can use Ctrl+Alt+C to open the Postman console in Postman.
Hello @Irfan.Khan
Here is the information you asked for. Nothing changed about the request body in between making these two requests. It is the same one as in my initial post. I just hit the send button again until it worked.
FAILURE (400):
Request Headers:
Date: Thu, 09 Jan 2020 09:35:46 GMT
Content-Type: application/json
Authorization: Signature keyId="{OUR_KEY_ID}",algorithm="hmac-sha256",headers="(request-target) host date content-type content-length",signature="rejW9suyS5T/XOfK+7/JDH7aopqVhMCldhKil+gD7Lg="
Content-Length: 639
User-Agent: PostmanRuntime/7.20.1
Accept: */*
Cache-Control: no-cache
Postman-Token: 21d799e8-27b0-4699-a290-b725fb814e2c
Host: rms-world-check-one-api-pilot.thomsonreuters.com
Accept-Encoding: gzip, deflate
Connection: keep-alive
Response Headers:
Transfer-Encoding: chunked Date: Thu, 09 Jan 2020 09:35:47 GMT Connection: close Server: ""
Response Body:
null
SUCCESS (200):
Request Headers:
Date: Fri, 10 Jan 2020 08:01:11 GMT
Content-Type: application/json
Authorization: Signature keyId="{OUR_KEY_ID}",algorithm="hmac-sha256",headers="(request-target) host date content-type content-length",signature="rNJJOPV2i3yOtXPN4BJ2VSmKuVgeIPzCa2t5htGdjsA="
Content-Length: 639
User-Agent: PostmanRuntime/7.20.1
Accept: */*
Cache-Control: no-cache
Postman-Token: 39c1a443-d3c9-4d4c-b494-00d4b8e254d2
Host: rms-world-check-one-api-pilot.thomsonreuters.com
Accept-Encoding: gzip, deflate
Connection: keep-alive
Response Headers:
Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 X-XSS-Protection: 1; mode=block X-Frame-Options: DENY X-Content-Type-Options: nosniff Date: Fri, 10 Jan 2020 08:01:14 GMT Content-Type: application/json;charset=UTF-8 Transfer-Encoding: chunked Server: "" Connection: close
Response Body
{
"caseId": "LOCAL_TEST_448eaadd-58cd-46df-9db7-4167572231af_2",
"results": [
{
"resultId": "5nzbfq8s45qw1eb02fkn5fzwc",
"referenceId": "e_tr_wci_2692",
"matchStrength": "EXACT",
"matchedTerm": "PUTIN,Vladimir Vladimirovich",
"submittedTerm": "Влади́мир Влади́мирович Пу́тин",
"matchedNameType": "AKA",
"secondaryFieldResults": [
... etc
],
"sources": [
"b_trwc_PEP N"
],
"categories": [
"PEP"
],
"creationDate": "2020-01-10T08:01:14.508Z",
"modificationDate": "2020-01-10T08:01:14.508Z",
"primaryName": "Vladimir PUTIN",
... etc
}
]
}
We are experiencing exactly the same problem. Some requests fail randomly, then succeed with the exact same payloads.
@dmitry34
We have had a live test where it seems that the special characters in the 'name' field have been the cause. @Irfan.Khan was able to replicate the behavior on his side.
It seems (so far) to work reliably in Pilot using only the standard english alphabet characters [a-zA-Z]. It fails occasionally (but succeeds after some retries) with non-standard characters as in my examples above (Влади́мир Влади́мирович Пу́тин).
Irfan has said that a ticket will be raised to investigate the issue.
@dmitry34
We received feedback from Irfan Khan that the issue had been resolved on Pilot. I have retested with party names:
Влади́мир Влади́мирович Пу́тин
习近平
Recep Tayyip Erdoğan
بشار حافظ الأسد
And all of these now work consistently (for us) on Pilot. We never noticed any issue on the Production environment.