reportDomain is stored on the profile and returned by the API — no code path reads it today
The profile field reportDomain exists so your tooling has a canonical place to record the hostname reports should be served from — but it is important to know exactly how far that goes.
Set it#
Include reportDomain in POST /v1/brand-profiles or PUT /v1/brand-profiles/:id (or pass null to clear it). It is a nullable string; there is no format validation beyond what your integration sends, and GET /v1/brand-profiles/:id returns it on every read alongside the colors and footer fields.
What reads it#
Nothing — today the field is stored and echoed back, and no report builder, delivery worker, or link generator consults it. Reports are delivered through this platform's own report links (the token URLs in the generated-report flow), not hosted on a per-profile domain. Record the value for your own systems and for future use, but do not expect attaching a profile to change where a report link points: destination URLs come from the schedule's targetUrl and the delivery payloads (see Choose a cadence).
Expected result#
A stored, retrievable domain on the profile — accurate metadata for your integration, with no behavioral side effects inside the platform.