API keys
Create and manage API keys for your server integrations.
A VYG API key lets a server call REST routes at https://api.vyg.app/v1 or MCP tools at https://api.vyg.app/mcp. The key belongs to one brand and carries only the scopes chosen when it was created.
Create a key
A brand admin opens Settings → API Keys, chooses the needed read scopes, and generates a key.
The new key starts with vyg_ and is shown once. Creating another key leaves existing keys active;
revoke an old key only after its callers have switched.
For a bot reading LiveRecover conversations, messages, contacts, and recovery performance, choose:
| Scope | Access |
|---|---|
conversations:read | Conversations, their messages, search, and conversation details with checkout and goal state |
contacts:read | Contacts |
campaigns:read | Campaign setup and campaign comparisons |
stats:read | Recovered sales, recovery rate, and other performance stats |
The optional brand:read scope provides the brand profile. The optional insights:read scope provides
conversation insights. Customer-data insights and other customer reads also require access
to customer data features.
Send the key as a bearer token in the Authorization header. Keep it on your server, never in browser
or mobile app code.
Authorization: Bearer vyg_…Manage keys over the API
The /v1/keys routes create, list, rotate, and revoke keys. They require an OAuth sign-in token with
keys:manage, available to brand admins. An API key cannot create, rotate or revoke
keys.
| Method | Path | Action |
|---|---|---|
| POST | /v1/keys | Create a key with an explicit scopes list; plaintext is returned once |
| GET | /v1/keys | List ids, prefixes, scopes, and dates without plaintext |
| POST | /v1/keys/{id}/rotate | Replace a key, keeping its scopes unless new ones are supplied |
| DELETE | /v1/keys/{id} | Revoke one key by id |
For a new vyg_ key, use key_class=cdp in these requests: as a query parameter on GET and DELETE,
and as a body field on the two POST routes. The chosen scopes determine which VYG API reads the key can
make. Use the key id, not its display prefix, when rotating or revoking it.
GET /v1/keys returns { "data": [...], "next_cursor": null } with every key in one page. Create, rotate
and revoke return the key record itself, not wrapped in data:
{
"id": "5b0f6c2a-3e1d-4f8a-9c7b-1a2d3e4f5a6b",
"key_prefix": "vyg_3f9c",
"brand_id": "b7a1c2d3-4e5f-4a6b-8c9d-0e1f2a3b4c5d",
"scopes": ["conversations:read", "contacts:read"],
"created_at": "2026-09-28T10:00:00.000Z",
"last_used_at": null,
"expires_at": null,
"revoked_at": null,
"plaintext": "vyg_…"
}plaintext is only on the record that create and rotate return, and only that once. The list and the
revoke response do not have it.
Some existing vyg_ba_ keys belong to the older provider integration flow. They remain separate from
new vyg_ keys and cannot read customer data.
Keep keys safe
Store each key in a server-side secret store. Give each integration its own key and only the scopes it uses, so you can revoke one integration without interrupting the others. If a plaintext key is lost, revoke it and generate a replacement.