Response and published keys

You already fetched Maya's published homepage hero. This page is the rest of that 200 — widget fields, child collections, CSS catalogs, how published keys look, and what a status code usually means. If you still need the first curl, go back to API Reference.

What the 200 is

You already fetched Maya's published homepage hero on API Reference. A 200 is { success: true, data }. This page is data — the widget, the collections in her tree, the CSS catalogs, how published keys look, and what a status code usually means.

The React SDK and <rulecms-widget> already parse this shape. If you render yourself, start at data.widget.itemList. That is the same tree the composer saved.

`data.widget`

The snapshot she published. For the homepage hero it looks like this:

Field	What it is
`publishedKey`	The key you sent — `{environmentId}---widget-…`.
`name`	The display name. “Homepage hero” if she named it that.
`version`	The published version string, such as `1.0.0`.
`environmentName`	`Staging` or `Production` — the environment this snapshot belongs to.
`itemList`	The rows and columns she dropped. This is what you render.
`tagName` / `tagDescription`	Optional release tag and notes from publish.
`lastPublishedAt`	When this snapshot was published.

`childCollections`

If the hero references collections — Maya's product card, an embedded sale block — those published snapshots arrive here. The map is keyed by each collection's published key, not by the Collection_… string you will also see inside itemList.

In itemList, a collection column type looks like Collection_{name}${publishedKey}. Nested copies append @ and the parent published key. The $… segment is the same string you use as a key in childCollections. See Collections and Publishing for shared versus embedded.

Each value is the same kind of snapshot as the widget:

{
  "publishedKey": "{environmentId}---collection-…",
  "name": "Product card",
  "version": "1.0.0",
  "environmentName": "Production",
  "itemList": { "rows": [ … ] },
  "lastPublishedAt": "…"
}

parentId is present when the collection is nested under another published resource. CSS catalog columns are stripped from these objects; catalogs land on data itself after a join.

CSS catalogs

The same GET may include the catalogs this widget (and the collections in its tree) opted to publish. Each catalog is its own toggle. Empty catalogs are omitted. When inclusion is off, the field is omitted and the response may set includeX: false for that catalog. The widget still 200s.

Field	When you reach for it	Off flag
`cssVariables`	Brand tokens such as `--brand-surface`. CSS Variables.	`includeCssVariables: false`
`classDefinitions`	Class names to declaration blocks. Class Definitions.	`includeClassDefinitions: false`
`fontFaces`	Stacks and loaded faces. Fonts.	`includeFontFaces: false`
`keyframes`	Animation names to frames. Keyframes.	`includeKeyframes: false`
`themes`	Host-condition token overrides. Themes.	`includeThemes: false`
`cssProperties`	Typed `@property` registrations. CSS Properties.	`includeCssProperties: false`
`widgetChrome`	Color-scheme, selection, caret, scrollbar. Widget chrome.	`includeWidgetChrome: false`
`classLayer`	`utilities` or `components`. Cascade layers.	`includeClassLayer: false`
`positionTry`	Custom `@position-try` names. Position try.	`includePositionTry: false`

The nine catalogs do not travel together. Turn fonts off and tokens still arrive. The Development draft GET uses the same field names, sourced from the live composer.

Published key formats

Shared widgets and shared collections use {environmentId}---{resourceKey}. Maya's Production hero is {environmentId}---widget-…. A shared product card is {environmentId}---collection-….

Embedded collections append ___ and the instance id: {environmentId}---{key}___{instanceId}. Two embedded copies can share a display name; the instance id keeps their published keys apart. That is why you copy the published key from Integration instead of assembling one.

How shared versus embedded behave on publish is Collections and Publishing. You will see those keys inside itemList references and as keys on childCollections.

When the GET does not work

Status is what you act on. The body may include a longer error string. Do not parse those strings for UUIDs.

You see	What it usually means
400	`publishedKey` is missing or not a string.
401	`token` is absent or empty.
403	The widget's team or environment does not match the token. A Staging token cannot fetch a Production hero.
404	Unknown token, disabled token, unknown published key, or the snapshot is not the active publish.
405	You POSTed or PUT. This route is GET only.

A dev. token on widget-cache is the wrong host. A draft widget-… key as publishedKey is the wrong query. Those belong on Development Integration.

How this fits

The hub teaches the request. This page teaches the body. Neither replaces the SDK or the HTML embed — those clients already consume this GET. A ruleset resolve returns the same widget shape with one extra field that says why that widget won.