Set up an assistant your visitors can trust.

Get started

1. Create a chatbot with a visitor-facing name.
2. Add a source and wait for Ready.
3. Ask real questions in Test.
4. Add your production hostname and widget snippet in Settings.

Overview

Overview combines source health, widget activity and recent conversations. Views measure widget loads; conversations measure an actual conversation. Use both signals to improve adoption.

Knowledge

Sources are the evidence available to the assistant. Add a single URL, a focused website section, or an uploaded document. For web sources write one path rule per line: /help/* includes a section, /pricing one page, and exclusions such as /login* always win. Large sites work best as focused sources, not one unrestricted crawl.

Appearance

Set colour, placement, launcher text and up to six suggested questions. Suggestions use a compact horizontally scrollable row. The widget retains a small Built with Knowera attribution.

Test

Test uses the same sources, instructions and Actions as your live widget but is visible only to your team. Use real visitor wording; adjust sources before adding more instructions.

Conversations & customers

Review full widget and internal-test transcripts, citations and fallback state. The list is paginated in groups of ten; repeated questions are the best input for improvements. The Customers workspace keeps one contact list for your whole organization: an email is captured automatically when a visitor writes it in chat or provides it to an Action. It does not infer an email from a name or external source.

Knowledge gaps & central playbook

Gaps group questions that could not be answered confidently. Add missing evidence to a source and re-index it when the answer belongs to a specific page. For recurring guidance across all chatbots, create a published Playbook entry instead. Playbook entries are approved facts, policies, voice guidelines, and links included on every reply; they never update themselves from visitors. Use a gap as a draft, then review and publish the accurate answer yourself.

Type @ in a Playbook instruction to find and mention an existing Action. The selected Action is displayed in bold in the saved instruction. This does not create another condition: the Action still starts only through its own trigger phrases, while the Playbook explains the tone, context and next steps around that workflow.

Response rules, Actions & webhooks

Actions match a visitor intent before the normal AI answer. They support both gentle, natural response guidance and deterministic workflows such as licence recovery, account lookup, booking, lead capture or a request to your own API.

Use a response rule for how the assistant should answer

To create a response rule, add trigger phrases and write the desired guidance in First response, then leave both Required fields and Webhook URL empty. Knowera gives that guidance to the assistant only when the rule matches. The assistant still writes a natural, context-aware answer in the visitor’s language rather than sending a fixed robotic message.

Write practical instructions: what to explain first, what not to promise, which link to use, whether to ask one follow-up question, and the right tone. For example: “For download questions, first identify the visitor’s platform. Link macOS visitors to [download URL]. Be concise and do not claim that a Windows version exists.”

Use an Action for a controlled workflow

1. Add trigger phrases, one per line. Exact phrases match first; Knowera then uses a safe two-term intent match. A rule containing lost license, forgot licence and resend license also recognises “I can’t find my licence”.
2. Write the first response. It is shown immediately when the Action starts.
3. Add required fields as Label:type, one per line. Supported types are text and email. Email is validated before delivery and saved to Customers.
4. Set an HTTPS webhook URL and, preferably, a signing secret. The Success response is shown only when the webhook returns 2xx.

A field label becomes a stable snake_case key in data. For example, Purchase email:email produces data.purchase_email. The friendly label remains in values for easy compatibility with simple endpoint implementations.

Delivery contract

After the final required field is collected, Knowera makes one HTTPS POST request with Content-Type: application/json and User-Agent: Knowera-Actions/1.0. It waits up to 10 seconds and accepts any final 2xx response. Redirects are followed; 3xx, 4xx, 5xx, timeouts and TLS/DNS errors are failed runs. The response body is ignored and never stored.

The endpoint must be publicly reachable from the internet over port 443 with a valid TLS certificate. Localhost, private IPs, custom ports and hostnames that resolve to private addresses are rejected to protect customers from server-side request forgery.

JSON body

{
  "event": "knowera.action",
  "action": "License recovery",
  "actionMeta": { "id": "UUID", "name": "License recovery" },
  "conversationId": "UUID",
  "values": { "Purchase email": "customer@example.com" },
  "data": { "purchase_email": "customer@example.com" },
  "question": "customer@example.com",
  "occurredAt": "2026-09-22T00:00:00.000Z"
}

values uses the labels configured in the UI; data uses machine-safe field keys and is the recommended integration format. question is the final visitor message, so use data for validated values. Values are masked in the Knowera audit log.

Signing-secret verification

When a signing secret is set, Knowera sends X-Knowera-Signature containing the raw hexadecimal HMAC-SHA256 digest of the exact raw JSON body. There is no sha256= prefix. Verify the raw bytes before parsing JSON and use a timing-safe comparison.

const crypto = require('node:crypto');\nfunction validSignature(rawBody, signature, secret) {\n  const expected = crypto.createHmac('sha256', secret).update(rawBody).digest('hex');\n  return signature && crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));\n}\n// Verify rawBody before JSON.parse(rawBody).

Test exactly what Knowera sends

Use the same public HTTPS endpoint, the same raw JSON shape and the same raw-hex signature. This command creates a compatible request:

BODY='{"action":"License recovery","values":{"Purchase email":"customer@example.com"}}'\nSIGNATURE=$(printf %s "$BODY" | openssl dgst -sha256 -hmac "$KNOWERA_SECRET" -hex | sed 's/^.* //')\ncurl -i -X POST https://example.com/webhooks/knowera \\n  -H 'Content-Type: application/json' \\n  -H "X-Knowera-Signature: $SIGNATURE" \\n  --data-binary "$BODY"

Why a terminal test can pass while an Action fails

A terminal runs from your own network. Knowera calls from its server, so an allowlist, firewall, WAF, IPv6-only routing, TLS configuration or IP-based rate limit can produce a different result. Another common cause is a webhook that expects action to be a text value or expects friendly field labels—both are now supplied in the contract above.

Debug a failed run

Open Actions → Recent action runs. HTTP 401/403 points to authentication or a signature mismatch; 404 is an incorrect path; 429 is endpoint rate limiting; 5xx means the endpoint failed. “fetch failed”, timeout, TLS or DNS errors mean Knowera could not establish the server-to-server connection. Response bodies are not exposed because they may contain private data.

Settings & install

Configure welcome and fallback messages, instructions and allowed domains. Use a hostname such as example.com; an empty domain list allows every site.

<script src="https://getknowera.com/widget.js"
  data-chatbot-id="YOUR-CHATBOT-ID" async></script>

The widget loads asynchronously and uses visible current-page content only to help answer a question about that page.