Thanks for the extra detail @jgoux! This is very helpful in understanding your use case. As you and I discussed in More control over Preview Environment in Pull Request, this is a workflow that we plan to support natively, without the need for custom solutions based on the API. That said, the API may be available before we implement this finer-grained control over preview environments.
You asked some smart questions, and they made me realize that I need to amend what I said before about deploying with a render.yaml file. My earlier suggestion was to turn off preview environments and use the same render.yaml for both the production branch and PR branches. But then you wouldn’t be able to use environment variable and plan overrides. Instead, what you might do is hit a “plan” API endpoint that tells you what resources the render.yaml file would create. Then you’d manually apply the overrides to those resource definitions and deploy the resources one at a time. This is more work, but at the end of it you’d have total control over suspending, resuming, and deleting the resources that comprise your preview environment. The other challenge is that if there are dependencies between the resources defined in the render.yaml file, you’ll have to manage those yourself. (For example: wait to deploy a service until the database comes up, grab the database connection string and store it in an environment variable for the service.)
As I said, the API schema is a work in progress. We’ll keep your use cases in mind as we finalize it.