Try the widget on localhost and staging before your real site.

Which test belongs where?

Each environment answers a different question. Dashboard tests check the answers, localhost checks the embed in your own build, and staging checks real HTTPS, headers and phones. Every call that starts a voice session uses a free conversation, wherever it starts.

1. Run a dashboard test first.

The dashboard won’t let you switch on an agent’s customer calls until it has approved knowledge, saved settings, at least one allowed origin and a completed test call from the dashboard. So the order is: approve knowledge, save the agent, add your local or staging origin, run a dashboard test, then switch calls on.

The REST API and MCP can switch calls on directly, so follow the same order yourself if you set up from code.

2. Allow your local address exactly.

Add the address exactly as your browser’s address bar shows it, including the port. http://localhost:3000 and http://127.0.0.1:3000 are different origins, so add the one you open, or both. Plain http works only for localhost and 127.0.0.1, and every other address needs HTTPS.

There are no wildcards. An entry such as https://*.example.com is saved as text but never matches a real address, so list each address you test from, up to 10 for each agent.

Serve the page from a local web server rather than opening the file from disk, because a file opened directly has no origin you can allow. Browsers treat pages from localhost and 127.0.0.1 as secure contexts, so the microphone works there without HTTPS, even though the call panel loads in an iframe from app.kawlnow.com.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Voice agent test page</title>
  </head>
  <body>
    <h1>Voice agent test page</h1>
    <script
      src="https://app.kawlnow.com/widget.js"
      data-helpline="YOUR_WORKSPACE_ID"
      async>
    </script>
  </body>
</html>

# Run this in the folder that holds test.html, then add
# http://127.0.0.1:8000 as an allowed origin and open
# http://127.0.0.1:8000/test.html
python3 -m http.server 8000 --bind 127.0.0.1

3. Allow one stable staging address.

Add the staging site’s exact HTTPS origin, such as https://staging.example.com. With 10 origins per agent, one stable staging address works better than preview deployments that get a new address for each build.

Test with the headers your production site will send. If staging sets a Content Security Policy or a Permissions-Policy header, it has to allow the widget’s origin and its microphone, as the widget embed reference describes.

To try a phone, open the staging site. A phone that loads your computer’s network address, such as http://192.168.1.20:3000, gets neither a secure context for the microphone nor an origin you can allow. A tunnel that gives your local server a temporary HTTPS address also works, if you add that exact address and remove it afterwards.

4. Switch calls on and check what visitors see.

The calls switch belongs to the agent, not to an address. Once it’s on, any page on any listed origin can start a call, so list only your test addresses until launch. Then check each state a visitor can meet.

• Before calls are on, the panel shows “This line is not accepting calls yet.”
• On an address that isn’t listed, the panel takes a topic and asks for the microphone, then shows “This domain is not allowed to use this support line.”
• On a listed address, the call connects and the conversation appears under Conversations. The export doesn’t mark it as a test.
• If calls fail on staging but work on localhost, check the staging headers before anything else.

How many free conversations will testing use?

Every call that starts a voice session uses one of the workspace’s 50 free conversations, whether it comes from the dashboard, localhost, staging or a customer. The allowance is one-time and shared by both agents, and paid calls aren’t available yet, so plan your test calls: group several checks into each call, and stop testing an area once it passes.

5. Move to production and tidy the list.

When staging passes, add your production origins, including both www and the bare domain if your site answers on both, and paste the script tag into your production pages.

Then remove localhost and any staging or tunnel addresses you no longer use. Your workspace ID is public in your page’s HTML, so anyone could load the widget from a page on their own computer at a listed localhost address, and those calls would use your allowance. Allowed origins depend on the browser’s Origin header; they aren’t bot protection.

The REST API and the update_agent MCP tool replace the whole origins list on each change, so send every origin you want to keep.

Common questions