Problem

Canvas Kit requests currently include workspace and admin information, but there’s no reliable way to determine which brand the app is being accessed from.

This is especially problematic for Home canvases, where there may not yet be an associated conversation. In those cases, apps cannot infer brand context from conversation data, making it difficult to build brand-specific experiences.

Suggested Solution

For Home canvases, the cleanest approach would be to include brand_id inside the existing context object.

Suggested request shape:

{
  "workspace_id": "abcd123",
  "admin": { ... },
  "context": {
    "location": "home",
    "brand_id": "15"
  }
}

Why this approach works well

• Keeps the payload structure consistent with the existing pattern of workspace + admin + context
• Places brand information alongside other “where the app is being used” metadata
• Avoids introducing a new top-level field
• Gives apps a reliable, conversation-independent way to determine brand context
• Enables clean integrations with multi-brand tooling and workflows

Example use cases

• Brand-specific Home experiences
• Conditional UI and workflows based on brand
• Analytics segmentation
• Multi-brand internal tooling integrations

Additional Notes

Apps can already map the returned brand_id to richer brand metadata using the Brands API. Exposing the identifier directly in Canvas Kit requests would provide the missing link needed to support reliable multi-brand experiences before a conversation exists.