WebSocket | Receiving error code 429 when not connected to VPN

We are using Reuters WebSocket API and receiving different responses for different usernames (with or without VPN):

Authentication request with credentials:
Endpoint: https://api.refinitiv.com:443/auth/oauth2/beta1/token 

Username 1:
Response: ERROR 429 {HTTP/1.1 429 Too Many Requests}

Username 2:
Response: SUCCESS 200 {HTTP/1.1 200 OK}

On the same time if we connect to the VPN we are getting success response for both the usernames (little strange):

Username 1 and Username 2 (When connected to VPN):
Response: SUCCESS 200 {HTTP/1.1 200 OK}

We have same code base for all these machines (Windows + Java 8)
Any help will be appreciated.
Thank You.

Best Answer

Answers


  • Hi Nick,
    Thank you for the reply and checking on this.

    We have tried with the given endpoint as well as with the latest code from Reuters RDP code, but still we are receiving the same error code 429 for one user and not for the other.

    And with the VPN, both the users are working fine with the old as well as new endpoint and codebase.

  • Hi @ranjeetchavan875

    It's unclear what you are doing within your application. The error code 429 occurs when the user has exhausted the maximum number of API calls per second. Are you sending a large number of requests simultaneously? Does this error occur if 1 request is sent? Does each user have their own Machine ID (Username) when they connect? For the Authentication 1 licensing, they should.

  • Yes, error occurs even with 1 request if not connected to VPN and same works when connected to VPN with the same code base (Nothing has changed on code base, little strange for me as well, as VPN should not matter in this case but it is now).


    I can understand below (Not sure whether this will be the case or not):
    We are sending consecutive requests every 10 seconds if authentication fails, so this may be blocking the IP at Reuters end and blocking my local machine and when I am connecting to VPN, I am getting new IP, which is getting allowed at Reuters end.

    Even if my local IP is blocked, it should get released automatically after some time and I should not get 429 error anymore, I even tried doing activity after 48 hours but still result is same as mentioned above.

    Your help will be really appreciated.
    Thank you in advance.

  • Hi @ranjeetchavan875

    I was just refreshing myself on this topic and re-read the entire thread - when you are not connected to VPN, you are receiving an error when you attempt to authenticate? That is, you have not even attempted to connect to a WebSocket server? I ask because you state this:

    "We are sending consecutive requests every 10 seconds if authentication fails"

    Which implies you can't even authenticate and has nothing to do with WebSockets at this points. Just curious, did you try the Java example within Git as opposed to your own code: websocket-api/Applications/Examples/RDP/java at master · Refinitiv/websocket-api · GitHub

  • Yes you are correct. Authentication itself is failing even tried with new RDP example:


    2023-10-04 20:31:55,517 [main] INFO com.service.provider.ReutersMessageProvider - EDP-GW authentication failure: 429 Too Many Requests

    2023-10-04 20:31:55,519 [main] INFO com.service.provider.ReutersMessageProvider - Text: {"error":"429" ,"error_description":"Request rate too high." }


  • Hi @ranjeetchavan875

    I have not heard of this issue before. If you know for sure your application that you are testing is only sending down 1 request and receiving error 429: Too many requests, then something between your application and the server may be inadvertently sending down multiple requests. I know that VPN would change the IP address and that without VPN, there may be a different network configuration/setup. If this is happening every single time, I would suggest you reach out to your network team to investigate to determine if there may be a blast of requests sent. All I can say at this time is that it appears to be specifically a network issue.

  • Yes, we are receiving ERROR:429 on very first request when not connected to the VPN.

    This issue started from:

    So earlier we had password expiration error on Production 2 days ago (no intimation received on password expiration) and service were tried to do authentication again and again and as per the documentation it may have blocked these authentication and resulted into ERROR:429.

    Later we have stopped that service on same day and no more API calls were done since last 2 days.

    Today we have received password reset link and we have done the password reset and enable back the API service and on the very first authentication we have received ERROR:429.

    It look like the Blocked IP/System from PROD environment has not unblocked from Refinitive side after password has been reset.

    So if we replace any other machine details (From lower environment) on Prod, it is working fine. (If there is issue with network then this should not also worked)

    If there is any WAP setting then request must not have reached till the Refinitive end and we also may not have response back.

  • Hi @ranjeetchavan875

    Thanks for the history and additional details. Given you were having success with the IDs until the password expired, it certainly does appear like this could be a server-side issue with the IDs. This Q&A site is dedicated to questions and issues with our APIs. This will require deeper investigation by the server teams for your specific IDs. For this, you will need to open a support ticket. Within the support site, select "Refinitiv products and content", then "I cannot access the product". Once selected, I would choose "Refinitiv Real-Time - Optimized" (the service you are using). Describe the issue(s) regarding the IDs expiring - you will need to provide your IDs within the ticket.

  • Hi Nick,

    Thank you so much for the throughout assistance.

    We have communicated with the Refinitiv team and got to know that this particular Machine ID was blocked the system, now they have unblocked it and we are successfully able to authenticate the service.

    Your help is really appreciated :)