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 (mall apps, multi-brand retail, white-label deployments) where each location needs its own greeting, tools, and conversation history but the codebase is shared.

Inheritance

A sub-project inherits everything from the parent unless explicitly overridden — greeting, initial message, critical instructions, tools, theme. Override only what differs. This means adding a new location is usually a matter of creating the sub-project and writing one or two location-specific overrides, rather than re-configuring an entire project.

Inherited values track the parent live: change the parent’s critical instructions and every non-overriding sub-project picks up the new value on the next message. Overridden values are independent — they stay even if the parent later changes.

Conversations & Analytics

Each sub-project has its own conversations and analytics. The parent’s Conversations and Analysis views aggregate across the parent itself plus all sub-projects; the per-sub-project views show only that child’s traffic.

SDK Side

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