Do the development and live versions need separate keys?

Technically no, since the version test path sits on the same origin and one allowlist entry covers both. In practice a second assistant for testing is worth it, so the conversations you generate while building do not mix into the record of what real users asked.

Can it answer questions using data from my app's database?

No. It answers only from the material you index, which means documents you upload and a crawl of pages that are public. Records held in your app are not part of that, and it will say it does not know rather than inventing an answer about them.

Does the launcher survive moving between pages in the app?

Yes. Because Bubble does not reload the document, the loader stays installed and the launcher stays where it is, including with a conversation open.

Why does it work on version test but not on the live app?

Almost always because the change has not been deployed to live yet. Check the live page source for the tag before looking at the key or the allowlist, because a missing tag and a refused origin produce the same empty corner.

Install guide

Installing a chat assistant on a Bubble app

Bubble keeps third-party tags in the SEO and metatags tab, which is not where anybody looks first. The other thing worth knowing before you start is that Bubble never fully reloads the document as a user moves around your app, and that turns out to work in the widget's favour.

The tag

<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>

Your own key replaces the placeholder. You will find it on the install tab of the assistant.

The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.

Where it goes on Bubble

Settings, then the SEO and metatags tab, then the field for script and meta tags in the body.

The script and meta tag fields live on the SEO and metatags tab of app settings. Check yours is editable before planning around it, and note that connecting your own domain, which any public app wants, is a paid plan feature.

Step by step

1Open the app editor, then Settings, then the SEO and metatags tab.
2Find the field for script and meta tags in the body rather than the header field above it.
3Paste the tag and replace the placeholder with your own key.
4Check it on the development version first. Bubble serves that under a version test path on the same address, so it needs no extra allowlist entry.
5Deploy to live. Until that runs, the live app keeps serving the previous version with no tag in it.
6Open the live app, hard refresh once, and confirm the launcher appears.

What goes wrong on Bubble

One document for the whole app

Bubble moves a user between pages without loading a fresh document. That suits this install: the loader installs once when the app first loads and stays put for the rest of the session, so the launcher does not flicker or duplicate as somebody navigates.

The flip side is that a changed tag is not picked up until a fresh document load. When you test an edit, hard refresh rather than clicking around inside the app.

Deploying is a separate act from saving

The Bubble editor saves continuously, so it feels like everything you type is already applied. It is applied to the development version. The live version changes only when you deploy.

The symptom is a widget that works on the version test address and not on the live app, which looks exactly like an allowlist problem and is not one.

The bubbleapps.io address and your domain are separate origins

An app keeps its bubbleapps.io address after a custom domain is connected, and a browser treats the two as unrelated. Cover both if anyone on your team still reaches the app through the original address, which on most teams somebody does.

Origins to allowlist

These are the origins a Bubble site is typically served from. List every one you want the assistant to answer on, including the ones only you visit.

https://your-app.bubbleapps.io
https://yourdomain.com
https://www.yourdomain.com

How the tag behaves, wherever you put it

The rest of this is the same on every platform, so it is worth reading once rather than on each guide.

Loader behaviour
One tag, nothing else	There is no second file, no stylesheet and no package to install. The tag is the whole install.
Where it goes	Immediately before the closing body tag. It works in the head too, because it defers, but the body keeps it out of the way of anything that measures render order.
data-key is required	Without it the loader stops and writes a warning to the browser console rather than rendering anything.
It finds itself	The loader reads the tag it was loaded from, and falls back to the first tag on the page carrying a data-key. Platforms that move or re-inject the tag do not break it.
It installs once	A second copy of the tag on the same page is ignored, so a template that renders twice does not produce two launchers.
Assets follow the tag	Everything else it needs is fetched from the same origin the tag was served from, so a proxy or a private domain needs no extra configuration.
The panel loads late	Only the small launcher is on the page at first. The conversation panel is fetched the first time a visitor opens it, in its own frame.
Styles cannot collide	The launcher renders inside a closed shadow root and the panel inside a frame, so nothing on the host page can restyle either, and neither can restyle the host page.

Set up on Bubble for a particular trade

The tag is the same everywhere. What is not the same is which of your pages the assistant can read once it is running, and on Bubble that depends on what kind of site this is. These go one level further than this guide.

For a healthtech appOne app wide script field, no route to keep it off the signed in screens, and a crawl that receives a shell instead of your copy.

Taking it off again

Clear the field on the SEO and metatags tab and deploy to live again. The live app carries the tag until that deploy completes.

Before you remove it

Removing the tag stops the widget on that site. It does not delete the assistant, its material, or the enquiries it has already collected.
If you are moving the widget to a different host rather than retiring it, add the new origin to the allowlist before you remove the old tag, or there is a window where neither works.

Questions

Do the development and live versions need separate keys?: Technically no, since the version test path sits on the same origin and one allowlist entry covers both. In practice a second assistant for testing is worth it, so the conversations you generate while building do not mix into the record of what real users asked.
Can it answer questions using data from my app's database?: No. It answers only from the material you index, which means documents you upload and a crawl of pages that are public. Records held in your app are not part of that, and it will say it does not know rather than inventing an answer about them.
Does the launcher survive moving between pages in the app?: Yes. Because Bubble does not reload the document, the loader stays installed and the launcher stays where it is, including with a conversation open.
Why does it work on version test but not on the live app?: Almost always because the change has not been deployed to live yet. Check the live page source for the tag before looking at the key or the allowlist, because a missing tag and a refused origin produce the same empty corner.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.

Start free See what it does