Products and routing
What a product is, how conversations get one, and how to fix the ones that don't.
This page explains the one idea that shapes the rest of Relay: every conversation belongs to a product. Once you know how a conversation gets its product, the settings for widgets, inboxes, knowledge bases, and the API all read the same way.
What a product is
A product is a thing you support. For a SaaS company that's usually the app itself; an agency might have one per client; a developer with several apps has one per app. A workspace can hold as many as your plan allows.
Products scope the things that should differ per product:
- which knowledge base the widget shows and the AI agent answers from
- the AI agent's context (name, description, product-specific prompts)
- helpdesk ticket numbering and Slack routing
- the product filter in the inbox, in search, and in the API
Manage them in Settings → Products. Open a product to edit its details and anything a use case adds to it.
How a conversation gets its product
Every inbox — a widget, a WhatsApp number, a Gmail mailbox — routes to one product. When a new conversation arrives on that inbox, Relay tags it with the inbox's product right then. That tag stays with the conversation; changing the inbox later doesn't rewrite history.
You set routing in Settings → Inboxes → Product routing: one row per inbox, with a product picker. A few things happen automatically:
- A widget inherits the product you connect it to in Settings → Inboxes → Widgets. Changing one changes the other.
- A workspace with a single product routes new inboxes to it.
- Onboarding creates your first product, widget, and inbox already linked.
Inboxes with no product show an Unassigned chip and a warning. Their new conversations arrive without a product — nothing breaks, but the AI has no product context and they won't show up in any product filter until someone assigns them.
If your workspace has more than one product and you connect a WhatsApp number or a Gmail mailbox, Relay can't guess which product it belongs to. Pick one in Product routing right after connecting.
Triage: conversations without a product
Sometimes conversations exist before an inbox is routed, or an agent needs to move one to a different product. Two tools cover it:
- In the inbox, open the product picker in the toolbar and choose No product. That view lists every conversation that still has no product, live.
- In the conversation sidebar, the Product section has a picker on every conversation in a workspace with more than one product. Changing it applies to that conversation only.
Once an inbox is routed, its existing conversations that had no product resolve through the inbox too, so the triage view usually empties itself the moment you assign the inbox.
Archiving a product
When you stop supporting a product, archive it from its page in Settings → Products (or from the ⋯ menu). Archiving:
- hides the product from every picker and stops counting it toward your plan
- keeps everything linked — conversations, tickets, widgets, and inbox routing all still point at it
- is fully reversible: Restore puts it back exactly as it was, subject to your plan's product limit
An inbox that still routes to an archived product is flagged in Product routing so you can point it somewhere else; until you do, its new conversations are still tagged with the archived product. Nothing new can be connected to an archived product.
Deleting a product is separate and permanent — prefer archiving.
In the API
Conversations carry a product object, GET /v1/public/conversations takes ?productId=<id> or ?productId=none, and GET /v1/public/products lists your products. See the API overview.
Next: Setup.