Configuration
Once the AI Assistant add-on is active (see Eligibility & Pricing), configure it per application from the admin dashboard.
Data-connection requires the AI Assistant add-on
Connecting a live HTTP endpoint or database is part of the AI Assistant add-on. If the add-on isn’t active for your organization, the tool configuration below won’t be available — enable it from Settings → Billing (available on Premium and Enterprise plans).
Setting up the AI Assistant
Enable the add-on
From Settings → Billing (super_admin only). See Eligibility & Pricing.
Configure a data source
Per application, connect exactly one data source: either an HTTP API or a read-only database.
- HTTP: a base URL and an allowed host — the AI can only reach GET endpoints on that host.
- Read-only SQL: a connection string for a database user that only has SELECT privileges.
Add tools
A tool is a named, described capability built on top of the data source — for example, "Look up order status by order ID". The AI chooses which tool to call, and with what arguments, based purely on the tool's name, description, and input schema. Write a specific, unambiguous description — that's the only signal the model has.
Send a test request
Every tool must be tested before it can be enabled. Run a test request with sample parameters and confirm it returns the data you expect.
Enable the tool
Once a tool has passed a test, flip it to enabled. Any later edit to the tool (name, description, schema, or config) resets it back to untested and disabled — it needs a fresh passing test before it can be re-enabled.
Turn on AI auto-respond
Per application, turn on auto-respond so the AI actually answers visitor messages. Until this is on, the assistant stays configured but silent for that application.
Preparing your endpoints (HTTP sources)
The AI doesn’t crawl your website — it calls API endpoints you expose. Any read-only JSON API works; you don’t need to build anything AI-specific. The requirements:
GETonly. Tools never send other methods, so every capability you want the AI to have must be readable viaGET.- JSON responses. Tool results are parsed as JSON; plain-text or HTML responses fail the test request.
- One host per application. All tools share the data source’s base URL and allowed host. If your data lives behind several services, route them through one API host (a small gateway/proxy is enough).
- Parameters go into the URL template you define — path segments
(
/products/{sku}) or query strings (/search?q={query}). The AI only supplies the values; it never composes URLs. - Keep responses small and relevant. Responses are capped (256 KB) and large payloads dilute answer quality — prefer endpoints that return the handful of fields the AI should quote.
- If the endpoints require auth, add the API key as a header on the data source — it’s stored encrypted and never shown again.
Worked example. DeliveryChat’s own assistant is configured this way — it answers pricing and setup questions using our public API:
| Tool | Description (what the model sees) | URL template |
|---|---|---|
getPlanInfo | ”Plan prices (BRL/USD) and per-plan quotas — how many API keys and members, the AI message cap, whether the AI add-on is available. Use ONLY for cost / ‘how many’ / ‘which plan’ questions, not for how a feature works.” | /api/v1/public/plans |
searchDocs | ”Search the docs — widget install, appId, API keys (what they are, when they’re required, how to authenticate), SDK, REST API, AI setup. Use for any ‘how do I / do I need / what is’ question about how the product works.” | /api/v1/public/docs/search?q={query} |
getDocsPage | ”Fetch the full text of one docs page by slug, from a searchDocs result. Use when the snippet isn’t enough.” | /api/v1/public/docs/pages/{slug} |
A typical e-commerce setup looks the same with different nouns: a
searchProducts tool over your catalog endpoint, a checkAvailability tool
over your stock endpoint, an orderStatus tool over your order-lookup
endpoint.
Have docs or FAQs instead of an API?
Expose them as a small search endpoint (query in, matching sections + links out) and register it as a tool — that’s exactly how DeliveryChat’s assistant answers “how do I install the widget?” questions from these very docs.
When two tools cover the same word, spell out the boundary
If a term appears in more than one tool — e.g. a plan tool has an apiKeys
quota and a docs tool explains what API keys are — say in each description
which questions it owns and which it does not. A description like “use for
anything about API keys” will pull the plan tool into “do I need an API key
for the widget?”, and the model will answer from a quota number that never
addressed the question. Scope by intent: quotas/prices go to the plan tool;
“how it works / do I need” go to the docs tool.
The read-only guarantee
The AI Assistant can only ever read your data — this is enforced by how the tools are built, not by asking the model nicely:
- HTTP tools are always
GET. The method is never configurable and never comes from the model. - SQL tools only run a single, stored
SELECT. Any write or schema keyword (INSERT,UPDATE,DELETE,DROP,ALTER, …) is rejected when you save the tool. - The AI never writes the request itself. It only supplies parameter values (like an order ID or an email) into a query or URL template that you defined. It cannot compose arbitrary SQL or arbitrary URLs.
Recommended: a SELECT-only database user
For SQL data sources, connect with a database user that only has SELECT
privileges on the tables the AI needs. This gives you a second layer of
protection beyond the read-only query validation, and keeps the AI’s access
scoped to exactly what it should see.
For HTTP sources, allowedHost must match the host of your configured base
URL — the AI can never reach an arbitrary domain, only the one you connected.