Brandfine Docs
REST API

GET /external/analytics-config

This workspace's analytics tracker config — website ID and script URL.

Returns the tracker config the consumer site uses to wire up Brandfine analytics. When analytics hasn't been enabled for this workspace in the CMS, returns { enabled: false } so callers can no-op cleanly.

GET /external/analytics-config
X-Api-Key: bk_live_xxx

Response (enabled)

{
  "enabled": true,
  "websiteId": "edb84e0d-b781-4812-a748-aa7bdc500228",
  "scriptUrl": "https://analytics.brandfine.co/script.js"
}

Response (not enabled)

{ "enabled": false }

Fields

FieldTypeNotes
enabledbooleanfalse when analytics isn't set up in the CMS. The rest of the fields are absent.
websiteIdstringUUID identifying this workspace's tracker. Goes into the data-website-id attribute on the script tag.
scriptUrlstringAbsolute URL of the tracker script. Loads the Umami tracker from the Brandfine analytics droplet.

This endpoint is deliberately minimal — it returns only what a consumer needs to inject the tracker. Admin credentials, internal site metadata, and anything else the customer doesn't already implicitly have stay behind the CMS's session-authenticated /ws/* surface.

CORS

Lives under /external/*, so it gets the same permissive CORS config every consumer endpoint does:

  • Access-Control-Allow-Origin: *
  • Access-Control-Allow-Headers: Content-Type, X-Api-Key

Safe to call from any origin with the workspace API key.

SDK

const cfg = await bf.analytics.getConfig()
if (cfg.enabled) {
  // build-time / manual injection
} else {
  // analytics not enabled in CMS — no-op
}

In practice you usually want bf.analytics.install() instead, which calls getConfig() internally and handles the script injection for you. See the SDK analytics guide for both patterns.

On this page