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

Best Answer

  • Irfan.Khan
    Irfan.Khan LSEG
    Answer ✓

    @lmeyeridricks

    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.

Answers

  • @lmeyeridricks

    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.

  • @dmitry34dmitry34

    We have had a live test where it seems that the special characters in the 'name' field have been the cause. @Irfan.KhanIrfan.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.


  • @dmitry34dmitry34


    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.

  • This is happening for me as well. Do I need to do any configuration or code change to fix this. I am still getting this intermittent bad request error both in the C# RDPExample program and in the development environment.