> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myustadia.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Course Brand

> Read, correct and approve a course's derived brand kit without having to find the preset behind it

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

```bash theme={null}
curl "https://api.myustadia.com/api/v1/courses/$COURSE_ID/brand" \
  -H "Authorization: Bearer sk_test_..."
```

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

<Note>
  **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.
</Note>

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.

```bash theme={null}
curl -X POST "https://api.myustadia.com/api/v1/courses/$COURSE_ID/brand/edits" \
  -H "Authorization: Bearer sk_test_..." \
  -H "Content-Type: application/json" \
  -d '{
        "edits": [
          {"op": "set", "path": "colors.primary", "value": "#49af55"},
          {"op": "delete", "path": "tagline"}
        ]
      }'
```

Each entry in `edits` is one operation against the brand kit:

| Field | Required | Meaning |
| - | - | - |
| `path` | yes | Dotted path into the brand kit, for example `colors.primary`, `fonts.heading`, `tagline`, `logo_url` |
| `op` | no | `set` (the default) or `delete` |
| `value` | for `set` | The new value. Ignored for `delete`. |

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.

<Warning>
  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.
</Warning>

## Approving the brand

```bash theme={null}
curl -X POST "https://api.myustadia.com/api/v1/courses/$COURSE_ID/brand/approve" \
  -H "Authorization: Bearer sk_test_..."
```

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.