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_xxxResponse (enabled)
{
"enabled": true,
"websiteId": "edb84e0d-b781-4812-a748-aa7bdc500228",
"scriptUrl": "https://analytics.brandfine.co/script.js"
}Response (not enabled)
{ "enabled": false }Fields
| Field | Type | Notes |
|---|---|---|
enabled | boolean | false when analytics isn't set up in the CMS. The rest of the fields are absent. |
websiteId | string | UUID identifying this workspace's tracker. Goes into the data-website-id attribute on the script tag. |
scriptUrl | string | Absolute 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.