Examples: Postman

Postman is convenient if you want to quickly build a working collection on top of API v2 without writing your own code.

What to put in the Environment

In most cases, four variables are enough:

• CP_URL — for example https://provisioner.spg99.ru;
• SPG99_TOKEN — your API key;
• TENANT — the tenant name;
• DB — the database name.

How to organize the collection

A practical structure looks like this:

Account

• GET {{CP_URL}}/v2/account/profile
• GET {{CP_URL}}/v2/api-keys/me
• GET {{CP_URL}}/v2/billing/summary

Tenants

• POST {{CP_URL}}/v2/tenants
• GET {{CP_URL}}/v2/tenants
• GET {{CP_URL}}/v2/tenants/{{TENANT}}
• GET {{CP_URL}}/v2/tenants/{{TENANT}}/credentials

Databases

• POST {{CP_URL}}/v2/tenants/{{TENANT}}/dbs
• GET {{CP_URL}}/v2/tenants/{{TENANT}}/dbs
• GET {{CP_URL}}/v2/tenants/{{TENANT}}/dbs/{{DB}}
• DELETE {{CP_URL}}/v2/tenants/{{TENANT}}/dbs/{{DB}}?force=true

Shared authorization

The most convenient option is to add a single shared header at the collection level:

Authorization: Bearer {{SPG99_TOKEN}}

And add Content-Type: application/json separately for POST and DELETE requests with a body.

Basic payload examples

Create a tenant:

{
  "name": "acme"
}

Create a database:

{
  "name": "app",
  "size": "L1"
}

Practical advice

• do not store a production SPG99_TOKEN in a shared team workspace without access control;
• do not keep pg_password in Postman history;
• after a questionable write operation, read the resource again with GET first and only then repeat the request;
• do not add manual start/stop/scale to the collection as part of a normal user workflow — they are disabled in the managed environment.

What to do if you need an OpenAPI import

If your environment publishes an OpenAPI specification, you can import it into Postman and use it as the basis for the collection. But even without that, a hand-built collection of a few requests is usually enough for all real everyday scenarios.