Balance and usage history

GET /v1/balance — your remaining prepaid balance. GET /api/key/usage — balance plus today/month spend and request counts per key. GET /v1/generations — paginated usage history. Examples in curl and Python.

Self-service: check your balance, programmatically fetch prices and view usage history for your key.

Balance

GEThttps://getvibeapi.com/v1/balance

Returns your remaining prepaid balance.

curl https://getvibeapi.com/v1/balance \
  -H "Authorization: Bearer $GETVIBE_API_KEY"
# → {"balance_rub": 1234.56, "currency": "RUB"}

Programmatic prices: /v1/pricing

GEThttps://getvibeapi.com/v1/pricing

The canonical price source for your account: models and variants, per-unit media prices. Returns an object with data (text models) and media (images and video). Prices are live, taking remote overrides into account.

curl https://getvibeapi.com/v1/pricing \
  -H "Authorization: Bearer $GETVIBE_API_KEY"

Each variant record has an addressAs field — the exact value for the model field in a request (e.g. claude-opus-4.8:yellow). The cacheReadRub field exists only for cache-enabled variants and shows the prompt-cache read price. Media records are marked estimated: true — the exact media charge depends on the actual generation volume and is returned in the x-pv-cost-rub; for streams, the body field requires x-pv-cost: 1.

Key summary

GEThttps://getvibeapi.com/api/key/usage

Returns the balance plus today's and this month's spend and today's request count. Authorizes with the same key sk-pv-… via the Authorization: Bearer header or x-api-key.

curl https://getvibeapi.com/api/key/usage \
  -H "Authorization: Bearer $GETVIBE_API_KEY"
# the same key is also accepted in the x-api-key header

Usage history

If you disconnect while a response is streaming, you pay only for the tokens the provider has actually confirmed as processed. If the stream ends before any output token and the provider confirms input tokens, only that input is charged; without confirmed usage, the charge is zero. Empty responses, provider errors, our cost-limit cancellations, and failed attempts replaced by a successful retry are not charged to you.

GEThttps://getvibeapi.com/v1/generations

Parameter	Type	Description
`page`	number	Page number. Defaults to 1.
`limit`	number	Page size, up to 100. Defaults to 20.
`dateFrom`	string (ISO)	Filter: from this date.
`dateTo`	string (ISO)	Filter: up to this date.
`request_id`	string	Only records for this request. The value comes from the project request-id header (x-getvibe-request-id).

curl "https://getvibeapi.com/v1/generations?page=1&limit=20" \
  -H "Authorization: Bearer $GETVIBE_API_KEY"
# optional filters: dateFrom, dateTo (ISO 8601), request_id
# request_id is the x-getvibe-request-id header value on getvibeapi.com
# curl "https://getvibeapi.com/v1/generations?request_id=$REQUEST_ID"

Example response:

{
  "data": [
    {
      "id": "...",
      "request_id": "8d4b6b3a-4f7c-4a4e-9a61-2f0c1d3e5b7a",
      "model": "gpt-6.1-sol",
      "route": "yellow",
      "address_as": "gpt-6.1-sol:yellow",
      "type": "text",
      "prompt_tokens": 120,
      "completion_tokens": 340,
      "total_tokens": 460,
      "units": 0,
      "cost_rub": 0.42,
      "created_at": "2026-06-15T10:00:00.000Z"
    }
  ],
  "page": 1,
  "limit": 20,
  "total": 1
}

The request_id field is the same id you received in the x-getvibe-request-id header on the original response. It is present on streamed answers too, so a stream can be matched to its record exactly. On a media record it is the jobId from the generation-submit answer.

The cost_rub field is the amount we debited for the event. The route and address_as fields show which public route actually served the request (see Routing → Flight breakdown). Only the client's own usage fields are returned.

A specific record: /v1/generations/{id}

GEThttps://getvibeapi.com/v1/generations/{id}

Returns a single usage-history record by its id. The request is owner-scoped: you only get your own events. The id comes from the GET /v1/generations response (the id field) or the x-pv-generation-id header of a non-streaming /v1/chat/completions response.

curl https://getvibeapi.com/v1/generations/USAGE_EVENT_ID \
  -H "Authorization: Bearer $GETVIBE_API_KEY"
# USAGE_EVENT_ID comes from the /v1/generations response (the id field)
# or from the x-pv-generation-id header of a non-streaming response
# find the record by request id: GET /v1/generations?request_id=$REQUEST_ID

Example response:

{
  "id": "cmpl_abc123",
  "request_id": "8d4b6b3a-4f7c-4a4e-9a61-2f0c1d3e5b7a",
  "model": "gpt-6.1-sol",
  "route": "yellow",
  "address_as": "gpt-6.1-sol:yellow",
  "type": "text",
  "prompt_tokens": 120,
  "completion_tokens": 340,
  "total_tokens": 460,
  "units": 0,
  "cost_rub": 0.42,
  "created_at": "2026-06-15T10:00:00.000Z"
}

Parameter	Type	Description
`id`req.	string (path)	Record identifier.
`mediaType`	string	Type: TEXT, IMAGE, VIDEO, AUDIO, MUSIC, MODEL_3D.

For streaming (stream: true) requests the record id is created asynchronously — the x-pv-generation-id header is absent. The record appears in history right after the stream finishes.

← PreviousMedia webhooks Next →Routing & limits