Skip to main content

Branding REST API reference

The branding REST API allows programmatic management of logos and brand colors. All endpoints follow existing Bravura Security Fabric REST API patterns (OData conventions, URL bracket notation for parameters).

Authentication and authorization

All endpoints require authentication. Write operations (PATCH, PUT, DELETE) additionally require:

  • A valid CSRF token

  • The appropriate OPA policy permission:

    • applicationsettings_get — Read branding configuration and logos

    • applicationsettings_patch — Update color configuration

    • applicationsettings_put_logos — Upload logo files

    • applicationsettings_delete_logos — Remove logo files

GET /api/rest/v2/applicationSettings

Retrieves the complete branding configuration including color settings and logo metadata.

Response: 200 OK with JSON body containing:

  • Color fields (primaryColorLight, primaryColorDark, secondaryColorLight, secondaryColorDark) in #RRGGBB format or null

  • Logo metadata for each uploaded logo type (filename, content type, dimensions, hash)

If no custom branding has been configured, the endpoint returns a valid response with null/default values.

PATCH /api/rest/v2/applicationSettings

Updates brand colors using JSON Patch format. Multiple colors can be updated in a single request.

Request body: JSON Patch operations targeting color fields.

Validation:

  • Color values must be in #RRGGBB format (6-digit hex)

  • Setting a value to null resets it to the default

  • Invalid formats (3-digit hex, named colors, invalid hex characters) return 400 Bad Request

Response: 200 OK with updated configuration. The branding.json file is updated in both ui/v2/assets/branding/ and design/custom/branding/.

Uploads a logo file for the specified type. The request body contains the raw file content.

Path parameter: {type} — One of: primary-light, primary-dark, logomark-light, logomark-dark

Validation:

  • Accepted formats: SVG, PNG, GIF, JPG

  • Maximum file size: 500 KB

  • SVG files are sanitized (scripts, event handlers, and external references are removed)

  • Dimension validation returns warnings for deviations from target sizes (upload still succeeds)

Response: 200 OK with logo metadata including the hash-based filename. Files are written to both ui/v2/assets/branding/ and design/custom/branding/. Old logo files are automatically cleaned up.

GET /api/rest/v2/applicationSettings/logos({type})

Returns metadata for the specified logo type, including filename, content type, dimensions, and content hash.

Response: 200 OK with metadata, or 404 if no logo of that type has been uploaded.

GET /api/rest/v2/applicationSettings/logos({type})/value

Serves the actual logo file with the appropriate Content-Type header and far-future cache headers (immutable, since filenames contain content hashes).

Response: 200 OK with binary file content, or 404 if no logo exists.

Removes the specified logo. The file is deleted from both storage locations and the branding.json configuration is updated.

Response: 200 OK on success, or 404 if the logo does not exist.

Skin rebuild endpoints

To deploy branding changes to the legacy Angular UI:

  • POST /api/rest/v2/applicationSettings (with action "rebuild") — Triggers a full skin rebuild as a background job. The rebuild runs make.bat default {lang} then make.bat install default {lang} for each installed language.

  • GET /api/rest/v2/applicationSettings/rebuild/status — Returns the current rebuild status with per-language progress (Pending, Building, Installing, Completed, or Failed).

Languages are determined by starting with en-us, then reading additional languages from ui/v1/assets/localizations/list.json.

File storage

All write operations update both locations simultaneously:

  • ui/v2/assets/branding/ — Immediate visibility for the React UI

  • design/custom/branding/ — Persistent source that survives skin rebuilds

Files use hash-based filenames for cache busting: {type}-{hash}.{ext}

In this section: