Rest API Devices 502

Completed

Elan Paul

October 23, 2025 14:39

Hello Support,

We are able to authenticate our user account successfully using the cdb/oauth2/token endpoint. When we try to get the devices from rest/v3/devices the request redirects with a 307 status code to a relay.vmsproxy url then responds with a 502 bad gateway error. We have many other accounts that we can successfully connect with and get the devices from. What might be possible issues on this account that would cause a 502 error and how we can diagnose these issues?

Thank you

0

• 

  Ichiro

  • Network Optix team

  October 27, 2025 06:16

  Hi Paul,

  Thanks for your post. Could you please provide the API request in full URL you have made?

  A 307 response is correct and expected behavior. It’s important that your implementation properly listens for redirects and handles the Location header in each request. (i.e. relay could be different for consecutive 2 requests)

  Unfortunately the information provided is limited, so we’re unable to jump to conclusions.  
  It is important to understand the steps you’ve taken. As a general guideline for issue reporting:

  • A minimum reproducible code sample is required.
  • The exact steps to reproduce the issue, or a screen recording, would also be very helpful.

  Thanks for your cooperation.

  0
• 

  Elan Paul

  October 27, 2025 14:10

  Hi Ichiro,

  The original API request is a GET request to https://3fbf5b8e-1a6f-464b-a16f-75773ca4cd37.relay.vmsproxy.com/rest/v3/devices, which gives us a 307 response and a new redirect url of https://3fbf5b8e-1a6f-464b-a16f-75773ca4cd37.relay-us-chi-1-prod-dp.vmsproxy.com:443/rest/v3/devices. We add the Bearer token as a header value as well as our authentication to the request. This second request is a GET request and returns a 502 status code.

  Thank you

  0
• 

  Ichiro

  • Network Optix team

  October 28, 2025 12:35

  Hi Paul,

  Please refer to this code sample for more details — it demonstrates a possible solution for handling redirects. (maybe this as well.)

  If you’re still experiencing issues, please provide a minimum reproducible code sample showing the exact request, the target relay, and how the request was made. This information will help us better understand and reproduce the problem.

   

  Thanks for your cooperation.

  0
• 

  Elan Paul

  October 28, 2025 14:55

  Hi Ichiro,

  Thank you for the code examples. We are able to get successful responses from the cdb/oauth2/token and rest/v3/devices endpoints for our other accounts. Regarding the specific response we are getting on this account, what would be the causes for a 502 bad gateway response on the request to rest/v3/devices? Is there something the end user needs to check or configure differently so this gets resolved?

  Thank you

  0
• 

  Ichiro

  • Network Optix team

  October 30, 2025 05:09

  Hi Paul,

  If other accounts are working properly in the same environment, this issue is likely specific to that particular account. However, with the limited information available, it’s difficult to determine exactly why this account is behaving differently.

  I suggest checking the user permissions and available resources for the affected account. You may also try creating a new system to test the account, or simply delete and re-add the account to see if that resolves the issue.

  Regarding the 502 error, it may indicate an unexpected response in the communication between the server and the cloud backend.

  If you can provide the system details and the specific account information, we’ll be happy to take a closer look.

  Thanks

  0
• 

  Elan Paul

  November 04, 2025 18:29

  Yes, is there a direct email address you can provide that we can send the specific account information to as to not have any security risks?

  Thank you

  0
• 

  Ichiro

  • Network Optix team

  December 16, 2025 08:12

  1. Usually, the 502 will be returned immediately by the relay, but in this case it seems like the backend is trying to reach the system for some time and then fails. 
  2. If you try to check the system health state as Cloud Backend detects it(e.g. by using GET /cdb/systems/{id} request), the cloud will report back such parameters values: "status": "activated", "stateOfHealth": "online". 
     Usually it could be trusted but in this case something is potentially off. Either the Mediator detects it as reachable but fails to complete the cloud connect or something else is in place. 

   As of the python script, it is mostly ok and will work for other cloud system ids with no issues(at least - for me). Ex:

  devices = requests.request('GET', 'https://%s.relay.vmsproxy.com/rest/v3/devices' % cloud_id, headers=auth_header, allow_redirects=False)
  redirect = requests.request('GET', devices.headers['Location'], headers=auth_header)

   

  Per response, this issue has been solved locally at the end.
   

  0

Please sign in to leave a comment.