Brand and template references are stored on the client but never auto-applied — each schedule still names its own
The client carries brandProfileId and defaultTemplateId, but understanding what they do — and what they deliberately do not do — keeps your integration from assuming inheritance the API does not perform.
What the fields are#
Both are optional references, validated on every save (unknown ids are rejected with the not-found errors described in Create a client) and returned on every read. They document which brand kit and report template your tooling should prefer for this client, and primaryUrl records the site in the same spirit.
What they are not#
Nothing downstream inherits them automatically. Schedule creation requires its own templateId — if it is missing or points outside the workspace, the save fails with Report template not found for this tenant. — and report generation resolves branding from the schedule's own brandProfileId, not the client's. The intended pattern for an integration is straightforward: read the client, take its references, and pass them explicitly when you create or update the schedule (see Choose a cadence).
Keep them honest#
PUT /v1/clients/:id re-validates whatever you send, so a deleted brand profile or archived template can be unlinked by writing null. A stale reference fails the next save rather than failing silently later.