401 UNAUTHORIZED when calling WorldCheck with name containing accents

Hi,
When calling the SEQ-screen-sync-individual: Perform Synchronous Screening: Individual API with a name containing accents, I have a 401 UNAUTHORIZED but when I call WorldCheck directly with Postman, I have a result. Is there something special to check with the encoding? I tried to change the encoding of the POST body with
For instance, when calling for "Stéphane Bern", I have the unauthorized answer. But without the accent "é", I have a result. The result seems to be the same than the one made with Postman. Are they in all case?
Thanks.
Best Answer
-
You can avoid the issue by encoding the request payload as ‘utf-8’ and then use it to calculate the content length of the payload.
This is mandatory if the user is trying to screen names with special characters. This is done to properly calculate the content byte length and not the string length.
As per my understanding, it’s the length of the content/payload sent to the API which determines that the request will succeed or not, if your request contains special characters. Also, when the payload is being sent in the request, it has to be sent as UTF-8 encoded.
Please find the simplified steps to achieve the same below:
- The content body should be converted to UTF-8.
- Calculate the length of the UTF-8 encoded content. Putting it simply, the length of UTF-8 encoded content is different than the normal payload body.
- Use the normal payload/content body in the dataToSign variable.
- Use the content length of the UTF-8 encoded in the dataToSign variable.
- Send the UTF-8 encoded content/payload in the API request.
- Send the content length of the UTF-8 encoded in the request header.
I advise you to send the same request using Postman. If it is successful, check the authorization headers and the content length in it and make sure the authorization header and the content length you are sending via your code is also the same. This should give you a success response.
Please do not include “charset”=UTF-8 as headers while sending your request, this will not solve the problem. We do not expect the charset in the request and hence it will result in error.
Kindly let me know if this helps by accepting the answer.
0
Answers
-
There is a simple way to fix this, you can change
payload.length()
to
payload.getBytes().length
on generateAuthHeaders implementation.
The content-length will be correct after this.0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 690 Datastream
- 1.4K DSS
- 629 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 559 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 25 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 280 Open PermID
- 45 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 716 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 95 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛