VBR REST API automation at scale: current limitations and future direction

[RestoreWizard2134578]

Hello,

This discussion originates from support cases 08019199 and 08241974, where I discussed automation requirements around VBR REST API and PowerShell with Veeam Support. During the latest discussion, I was encouraged to bring the topic to the R&D forums to gather additional customer feedback and enable broader discussion with Product Management.

We manage a number of Veeam environments and are increasingly evaluating REST API as the long-term automation platform.

Historically we have relied heavily on PowerShell automation. However, recent discussions around the future redesign of older PowerShell cmdlets, together with the general industry trend towards API-driven automation, have made us take a closer look at what can be achieved with the native VBR REST API.

While testing and developing automation workflows, we have encountered several situations where simple administrative tasks require significantly more effort through the REST API than expected.

One example was a requirement to update job descriptions across hundreds of backup jobs. While this is technically possible through the REST API, it requires retrieving and resubmitting a larger job configuration object even when only a single field is changing.

The job description example is not really the issue itself. Rather, it highlights a broader question:

How does Veeam Product Management view the future role of VBR REST API for automation?

Some topics I would be interested in hearing more about are:

- Support for partial updates.
- PATCH-style operations for modifying only specific fields.
- Metadata-only update operations.
- Reduced need to resubmit complete object definitions when only a small change is required.
- Feature parity between PowerShell and REST API.
- Best practices for managing large numbers of objects through automation.
- The long-term relationship between PowerShell automation and REST API automation.

We are not looking for a workaround to a specific task. We are more interested in understanding whether there is a broader vision for making REST API the primary automation interface going forward and, if so, which areas are currently considered candidates for improvement.

I would be very interested to hear feedback from both Product Management and other customers who are heavily invested in Veeam automation using either the VBR REST API, PowerShell modules, or a combination of both