Cloud Auth Bearer token getting Auth_MissingCredentials on database backup endpoint even for Owner

Hi,

I'm trying to automate configuration-only backups over DW Cloud relay using the public REST API and running into a consistent permission issue.

Goal

Trigger a named system database backup (preferably using the modern server-side method POST /rest/v3/servers/this/dbBackups) from a third-party tool when the system is only reachable via Cloud relay.

Setup

System is connected to DW Cloud
Using a Cloud Owner account
Obtaining tokens via POST /cdb/oauth2/token with grant_type=password + scope: cloudSystemId=...
Following the two-token pattern from the official examples (system-scoped token + cloud-only token)
Re-requesting fresh tokens at the moment of backup (to mimic the Desktop Client confirmation step)
Using the cloud-only token (no cloudSystemId scope) for the actual privileged calls, as recommended for Cloud DB operations
Also tried generating tickets (POST /rest/v*/login/tickets) and using _ticket
Tried both the old pull method and the server-side backup endpoint

What works

Basic reads over the relay with the Cloud Bearer work (e.g. /rest/v1/system/info returns 200)
Full configuration backup works fine when using local admin credentials directly (no Cloud relay)

What fails

Every privileged database backup path over Cloud relay returns Auth_MissingCredentials:

POST /rest/v3/servers/this/dbBackups
GET /rest/v*/system/database
POST /rest/v*/login/tickets (even this fails)

The documented "Remote Server proxy method" (POST /proxy/https-insecure/.../rest/v4/login/sessions) using Cloud Bearer + local admin password also returns Auth_MissingCredentials.

This happens even when re-sending the Cloud password as confirmation at the exact time of the backup call.

Question

Is there a known limitation with Cloud OAuth identities (even Owners) performing database backup operations over the relay using the public REST API?

If so, what is the recommended approach for third-party automation tools to trigger configuration backups on Cloud-connected systems?

Are we missing a specific confirmation step, header, or different token usage that the Desktop Client uses internally?

Any guidance would be greatly appreciated.

Thanks!

Ichiro

Network Optix team

June 04, 2026 11:03

Based on what you shared, this doesn't look like a bug. Let me walk you through what's actually happening.

We assume when you connect through the cloud relay, your requests go to:

https://{cloud_system_id}.relay.vmsproxy.com

And the Auth_MissingCredentials is self-explanatory, potentially your auth token is not reaching the server. The most common reason: your implementation may be missing handling HTTP redirects.

When the server redirects your request, your token needs to be included in the redirected request too, not just the first one. Most HTTP clients strip headers (including Authorization) when they follow a redirect, so you have to handle this manually. (or explictly)

So,

Please refer to this article first: https://support.networkoptix.com/hc/en-us/articles/34032455073431-Handling-HTTP-HTTPS-Request-Redirection
Then may be take a look at this working Python example on GitHub: https://github.com/networkoptix/nx_open_integrations/blob/488b5a6ec4b132467ff7d6c09880849a571227d3/python/examples/common/server_api.py#L31

It shows exactly how to attach your token to redirected requests.

To answer your other questions directly

There is no known limitation preventing Cloud OAuth owners from running database backups via the REST API over the relay.
The Desktop Client does not use any special or different tokens. There's no hidden auth mechanism, it uses the same token you have access to.
There is no missing confirmation step or special header beyond handling the redirect correctly.

Maybe fix the redirect handling first and test again. That should resolve it.