LiveRecoverVYG Developer Docs
Brand Data API

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_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The 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:

SituationCause
Missing headerNo Authorization header was sent.
Malformed headerThe header is not in Bearer <key> form (e.g. wrong scheme, empty token).
Unknown keyThe key does not match any issued credential.
Revoked keyThe key was revoked, from the dashboard or via DELETE /keys/{keyId}.
Expired keyThe key had an expiry and it has passed.
Wrong kind of keyA CDP key was presented. It is not valid on this API.
Disabled integrationYour 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.

On this page