🚀 Exciting news for Service Providers!

Veeam Service Provider Console (VSPC) v9 just dropped, and it comes packed with some really cool new features. Over the past few days, I’ve been digging into one in particular—REST API proxying—and wanted to share what I’ve discovered, plus a small demo script that shows just how powerful this feature can be.

So, what’s REST API proxying?

Simply put, VSPC can now use a single API token to authenticate itself and then proxy requests to all your remotely managed Veeam products. That means you can manage everything from one central console without juggling multiple keys or credentials.

A note on security

Because a single API key can reach all your servers, it’s super important to keep it safe. Treat it like gold. 😄

When you create an API key, you can also enable “read-only access.” This applies not only to calls against VSPC itself but also to all proxied requests to your Veeam servers. If you’re just pulling information (like in my demo), enabling read-only is the way to go.

You can find the official documentation for this feature here: https://helpcenter.veeam.com/docs/vac/rest/proxying.html?ver=9

I decided to dive in and do some scripting myself—the script is attached to this post. Essentially, it’s a wrapper for GET requests to one or multiple destination Veeam servers, and it really highlights the power this feature gives us as service providers.

The script does only GET requests. And if you enable read-only access to the API key, nothing can break 😁

Here’s a quick overview of how it works:

The script requires a config.json file in the same directory (or you can update the script to point to a different location). This config file also specifies the location of your API key.

Here’s an example config.json file:

{
  "ApiKeyPath": "C:\\Users\\xxx\\Desktop\\api-key.txt",
  "Server": "vspc.domain.com",
  "Port": 1280,
  "ApiVersion": "v3"
}

With this setup, the script reads the config, authenticates with VSPC using your API key, and can send GET requests to your managed Veeam servers effortlessly.

Here’s how the script works:

1. Load the config: The script starts by reading the config.json file and retrieving all organizations and their management agents via an API request.
2. Select the Veeam product: Choose which Veeam product you want to send the API request to
3. Choose the target agents: Decide whether to run the query against all agents, all agents within a specific organization, or just a single agent.
4. Select the organization: Once chosen, the script lists all compatible agents within that organization.
5. Enter the API request: Finally, input the exact API request you want to run.

After that, the script returns the response from the agent—or agents—you queried, giving you direct insight into your managed Veeam servers.

Some Findings While Testing REST API Proxying

• VBR REST API requires the x-api-version header in requests. This is mandatory for VBR (tested on 12.3; likely required for v13 as well). In VB365, this header is not needed. My script includes it by default, but you may need to adjust the version value if using the latest API with v13 for example.
• API URLs differ slightly between products: When querying a VBR, the URL must include /api. For VB365, this is not required—just something to keep in mind.
• Always follow the official REST API documentation and use the API URL exactly as written:
  • VBR 12.3 → Documentation
  • VBR 13 → Documentation
  • VB365 → Documentation
  • VeeamOne 13 → Documentation

This script is really just the tip of the iceberg. REST API proxying allows us to manage everything exposed by the Veeam product APIs from one centralized location, across all managed servers (VBR, VB365, VONE).

VSPC already provides a lot of data, and each new version adds more. But there are still some gaps—things that are now possible with this proxying feature that weren’t possible before:

• Monitor VBR configuration backups – a long-requested feature that is still not directly available through VSPC.
• Check notification settings – verify if email notifications are enabled, or if an admin temporarily disabled them for maintenance and forgot to re-enable. This can be especially tricky if the customer has access to VBR as well.
• VB365 reporting – generate per-customer reports on job exclusions, something I’ve had several feature requests for.
• Upgrade preparation reports – for v13 upgrades, identify all customers who haven’t upgraded to the v12 backup chain format or are still using legacy backup copy or reverse incremental jobs.
• Automation possibilities – for example, automatically creating VB365 jobs on any server, whether hosted or on-premises.

The possibilities really are nearly endless.

💡 Question for the community: What else could we do with this feature beyond the examples above? I’m excited to explore and implement more of these scenarios in the near future!