Sub-Projects

Sub-projects let one parent project serve multiple tenants from the same SDK install — same API key, but the SDK passes a subProjectId to route to the right child. The classic case is a single mobile app shared across many physical locations where each location needs its own greeting, documents, and conversation history but the codebase is shared.

Available on plans that include sub-projects, with a per-plan cap on how many sub-projects a project can have — see Billing.

What’s Shared, What’s Additive, What’s Its Own

Most configuration is either fully shared with the parent, or layered on top of the parent’s — very little is fully independent:

• Tools and navigation rules are always the parent’s — there’s no Tools or Navigation Rules page under a sub-project, and nothing here can override them.
• Instructions are additive: a sub-project’s own instructions are appended after the parent’s, not a replacement. The parent’s instructions always apply.
• Greeting Message and Initial Message use override-with-fallback: leave them empty on the sub-project to inherit the parent’s value, or fill them in to override it.
• Documents are additive: at chat time, the assistant searches the parent’s documents together with the sub-project’s own.
• Chat Theme is layered: the sub-project’s theme settings are merged on top of the parent’s, field by field — not a full replacement.
• External Destinations are additive: both the parent’s and the sub-project’s own are available.
• Members — parent project Owners and Admins can view all its sub-projects; to edit a sub-project, or to give a parent Viewer access, add them on the sub-project’s own Members page.

Each sub-project has its own Documents, Conversations, Chat Test, Chat Theme, Members, and External Destinations page, plus its own name, description, and a fixed identifier (set at creation, read-only afterward) used as the subProjectId value.

Conversations

Each sub-project has its own conversation history. The parent’s Conversations page can scope the list to parent + sub-projects combined, the parent only, or one specific sub-project. There’s no per-sub-project Analysis page or parent-only analysis scope — analysis runs at the parent level.

Enable, Disable, Delete

A sub-project can be disabled without deleting it — this takes it offline without losing its configuration.

Deleting removes the sub-project from the dashboard and takes it offline immediately. For 30 days its identifier stays reserved and it still counts toward your sub-project limit, after which both are freed up.

SDK Side

The SDK takes subProjectId as a top-level prop on <Qafka /> — not inside context. See the Sub-Projects guide for the full SDK contract: switching at runtime, identifier conventions, voice limitations, and common patterns.