Войти

Примеры: Postman

Stable

Коллекция Postman и как её обновлять (preview).

Обновлено: 5 марта 2026 г.

Postman удобен, если вы хотите быстро собрать рабочую коллекцию поверх API v2 без собственного кода.

Что положить в Environment

Обычно достаточно четырёх переменных:

  • CP_URL — например https://provisioner.spg99.ru;
  • SPG99_TOKEN — ваш API key;
  • TENANT — имя tenant;
  • DB — имя базы.

Как организовать коллекцию

Практичная структура такая:

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

Общая авторизация

Самый удобный вариант — добавить один общий заголовок на уровне коллекции:

Authorization: Bearer {{SPG99_TOKEN}}

И отдельно Content-Type: application/json для POST и DELETE с телом.

Базовые payload‑примеры

Создание tenant:

{
  "name": "acme"
}

Создание базы:

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

Практические советы

  • не храните рабочий SPG99_TOKEN в общей team‑workspace без контроля доступа;
  • не сохраняйте pg_password в Postman history;
  • после спорной write‑операции сначала перечитывайте ресурс через GET, а уже потом повторяйте запрос;
  • не добавляйте в коллекцию ручные start/stop/scale как часть обычного пользовательского сценария — в managed‑контуре они отключены.

Что делать, если нужен OpenAPI‑импорт

Если в вашем контуре опубликована OpenAPI‑спецификация, её можно импортировать в Postman и использовать как основу коллекции. Но даже без неё ручная коллекция из нескольких запросов обычно закрывает все реальные повседневные сценарии.

Почему SPG99АрхитектураПлан развитияДокументацияБлог