Your interface. Our answers.

An ask box for your help centre, docs, store or app. Same assistant as the widget, same knowledge, same inbox — one tag or one hook.

Live — it answers from this site's own docs.

Start free Read the docs

One key

The public key the widget already uses. Nothing new to issue or secure.

Your markup

An input you already have; answers streamed into your page. No iframe.

Cited answers

Every reply links the page it came from, exactly as in the widget.

One inbox

Headless threads land beside widget chats — ratings, leads, handoff.

Where it lives

Four places questions start.
One assistant answers in all of them.

Pick a surface. Every box below is live and answers from this site's own docs.

A glowing search bar on a dark glass floor, with three glass category tiles floating above it.

How can we help?

Ask a question, or browse the guides below.

Getting startedBillingSecurity

The search bar, answering

A help centre that replies instead of listing

Most help-centre searches return twelve articles and lose the visitor on the way to the right one. Put the answer in the bar itself, with the article linked underneath.

Answers in the visitor's language
Sources listed under every answer
A person offered when the content runs out

From the widget to your page

Live in an hour, on the bot you already have.

Step 01

Take your key

From Setup in the dashboard. It identifies the bot and authorises nothing, so it is safe in client code.

Step 02

Allow the page

Headless pages are checked against the bot's allowed domains, like widget pages. Add the subdomain your docs live on.

Step 03

Paste, or import

One tag renders a finished ask box. The packages give you the state — messages, streaming, sources — and you render.

In whatever you write

index.html

<script async src="https://app.matterchat.co/askbox.js"
  data-key="YOUR_BOT_KEY"
  data-suggestions="Pricing|Refunds|Shipping"></script>

Why not just the bubble?

The question is asked where the widget is not

A chat bubble sits in the corner of every page and answers whatever it is asked. But most questions are born somewhere specific: in a help-centre search bar that returns twelve articles, on a product page two clicks from checkout, on a settings screen where the answer is one field away. A widget is a detour from all three.

Your help-centre search returns articles, and people leave without reading them
Product pages get the same shipping and returns questions in reviews and in support
Users email support about settings they were already looking at
Your docs site has search, but the answer is spread across three pages

Questions developers ask first

Short answers. The last row is the product: ask it anything the list missed.

Do headless answers count against the same plan as the widget?

Yes. Every answer is a reply on the bot's plan, whichever surface asked it. There is no separate API tier for headless in the browser; the server-side REST API remains an Agency feature.

Can I run the widget and a headless box on the same site?

Yes, and many sites will: the widget everywhere, an ask box on the help centre. They use the same key and the same knowledge, so an answer is the same in both.

Does the ask box need a build step?

No. The script tag is a complete ask box. The packages are for teams that want to render the answer inside their own components.

Is the public key safe to expose?

It is the same key the widget already exposes on every page it runs on. It identifies the bot; the allowed-domains list and the session handshake decide who may ask.

Can a signed-in user's identity travel with the question?

Yes. Pass the same id and server-signed hash the widget accepts. Unsigned ids are ignored rather than trusted.

All solutions