For a deeper look into our World Check One API, look into:

Overview |  Quickstart |  Documentation |  Downloads

question

Upvotes
Accepted
5 3 5 11

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.

world-checkworld-check-one
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

@cao-trung.do,

Thank you for your participation in the forum. Is the reply below satisfactory in resolving your query?

If yes please click the 'Accept' text beneath the reply. This will guide all community members who have a similar question.

Otherwise please post again offering further insight into your question.

Thanks, AHS

Upvote
Accepted
4.2k 8 5 6

@cao-trung.do

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:


  1. The content body should be converted to UTF-8.
  2. 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.
  3. Use the normal payload/content body in the dataToSign variable.
  4. Use the content length of the UTF-8 encoded in the dataToSign variable.
  5. Send the UTF-8 encoded content/payload in the API request.
  6. 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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
1 0 0 0

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.