Authentication
Obtain a Brand Data API key, present it as a bearer token, and understand what it can and cannot reach.
Every Brand Data API endpoint except GET /health
requires authentication. Data endpoints authenticate with a Brand Data API
key, sent as a bearer token.
Getting a key
Mint one from Settings → Brand Data API in the LiveRecover dashboard.
The key is shown exactly once, at the moment it is created. We store only a hash of it, so it cannot be shown again and it cannot be recovered — if you lose it, revoke it and mint a new one. Put it straight into your platform's secret store.
Your keys look like this:
vyg_ba_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxThe vyg_ba_ prefix is deliberate: a Brand Data API key is scoped to this API
only. It is not a CDP key, it will not authenticate against the CDP API or the
MCP server, and a CDP key will not authenticate here. The two are separate
credentials with separate lifecycles — rotating one never touches the other.
The Authorization header
Authorization: Bearer <your-api-key>curl -sS https://<your-vyg-api-host>/conversations \
-H "Authorization: Bearer $LIVERECOVER_API_KEY"Managing your keys
You can also mint, list, and revoke keys over the API, at /keys.
These endpoints are authenticated by your dashboard session, not by an API
key. That is on purpose: an API key can never be the credential that mints
another API key, because a leaked key could otherwise mint itself a replacement
and survive being revoked. Presenting any vyg_-prefixed token to /keys
returns 403 Forbidden.
Listing keys returns their display prefixes only — never the key itself.
Revoking takes effect immediately: the next request carrying that key gets a
401.
What the key resolves to
Your API key is bound to exactly one brand. On every request, LiveRecover resolves your key to that brand and scopes the entire response to it. You cannot widen this scope, and you never pass a brand identifier yourself — the key alone determines what you can see and change.
This means:
- List endpoints return only your brand's records.
- Fetching or updating a record by id that belongs to another brand returns
404 Not Found— identical to an id that does not exist. The API never reveals whether another brand's id exists.
Legacy integration keys
If you connected a Custom Integration before Brand Data API keys existed, you
were issued a key beginning vyg_live_. Those keys still work, for reads and
writes alike.
They are deprecated. A vyg_live_ key is minted per provider but carries
authority across your whole brand, which is not what its name suggests. Move to
a vyg_ba_ key when you can, and revoke the old one once nothing depends on it.
Failure modes
All authentication failures return 401 Unauthorized with the same body, so the
response never reveals whether a particular key exists:
{ "error": "Unauthorized" }You will receive a 401 when:
| Situation | Cause |
|---|---|
| Missing header | No Authorization header was sent. |
| Malformed header | The header is not in Bearer <key> form (e.g. wrong scheme, empty token). |
| Unknown key | The key does not match any issued credential. |
| Revoked key | The key was revoked, from the dashboard or via DELETE /keys/{keyId}. |
| Expired key | The key had an expiry and it has passed. |
| Wrong kind of key | A CDP key was presented. It is not valid on this API. |
| Disabled integration | Your integration has been disabled on the LiveRecover side. |
If you receive a 401 you believe is incorrect, confirm the key value and that
your integration is still enabled, then contact your account contact. Do not
retry a 401 — the outcome will not change until the request is corrected.
A 403 Forbidden is different, and means the request authenticated but was not
allowed: either the integration surface is not enabled for your brand, or you
presented an API key to a /keys endpoint. See Errors.