Skip to main content
A course created without a preset still gets a brand. The platform derives one from the source material and holds it in a hidden preset bound to that course. These three routes let you read, correct and approve that brand from the course itself, so a client working from a course object never has to discover the underlying preset id.

​
Reading the brand

Returns the brand as a reviewable artifact: its content, its status, and whether it is waiting on you.

​
A 404 here means absence, not an error

GET /courses/{id}/brand returns 404 in three distinct situations, and it deliberately does not tell you which one:
  • the course has no preset at all
  • the course’s preset is not auto-derived, meaning you supplied a preset yourself
  • a brand has not been gathered for it yet
Courses created from a preset you supplied always return 404 here. That is correct and expected. Their brand review lives on the preset, not on the course: use GET /presets/{preset_id}/brand instead. Do not treat this 404 as a failure or retry it.
If you are polling a freshly created no-preset course, a 404 simply means the brand is not ready yet. Keep polling GET /courses/{course_id}/status and try again once the course reports that a brand review is pending.

​
Correcting the brand

A brand derived from a URL is frequently wrong rather than merely uncertain, most often the colour palette. Approve-only would leave you stuck with it, so edits are supported before approval.
Each entry in edits is one operation against the brand kit: Which paths are valid depends on the fields the kit itself carries, so read the brand first and edit paths you can see in the response. This is the same dotted-path shape as POST /presets/{preset_id}/brand/edits. The course route resolves the bound preset for you and then applies the identical operation, so behaviour matches the preset route exactly.
Check the palette against the logo before approving. A derived palette can be confidently wrong, and once the brand is approved the course resumes generating with those colours.

​
Approving the brand

No request body. Approving releases the hold and the course resumes generating, and it fires the same webhook as approving on the preset route. Two behaviours worth relying on:
  • It is idempotent. Approving an already-approved brand is safe and will not double-resume the course.
  • It is not gated on the course’s status. The brand asset itself is the gate. This matters because a course can be reporting a status that does not reflect a pending brand, and a status-gated approve would then be unreachable.

​
The order to use them in

  1. GET /courses/{course_id}/brand. A 404 means no brand to review, see above.
  2. Inspect the palette, fonts and logo. Compare the palette against the logo.
  3. POST /courses/{course_id}/brand/edits for anything wrong. Repeat as needed.
  4. POST /courses/{course_id}/brand/approve. The course resumes.