Add an AI Chatbot to Your Bubble App

What connecting Bubble gets you

A Bubble app is usually somebody's product, not a brochure — which changes what support looks like. The questions aren't "what are your hours". They're "how do I do the thing", asked by a user who is already inside the app and already stuck. That user doesn't want a docs site in another tab. They want the answer where they are.

Connect Evoriqa and an AI agent trained on your help content answers in place, on every page of the app, and hands off to your team with the full transcript when the answer isn't in the docs. One snippet, no plugin, no workflow to wire up.

Where the snippet goes

Bubble keeps custom script tags in a place its name doesn't advertise: the Settings tab, under SEO / metatags. In the advanced settings there you'll find two fields — **Script/meta tags in header** and **Script in the body**.

The Evoriqa snippet goes in Script in the body. Bubble's own documentation is blunt about this field: _"Be careful with what you add here as improper code added here can break your app."_ That's fair warning and it applies to anything you paste — our snippet is a single async <script> tag, which is about as inert as custom code gets, but paste it, save, and test rather than stacking five changes at once.

Header field or body field

Use the body field, and it isn't only a preference.

The header field accepts a narrow set of tags — per Bubble, _"the only valid header tags are <script>, <meta>, and <link>"_ — and anything invalid ends up moved into the body by the browser's own repair logic anyway. Putting the widget in the body from the start means what you see in the settings panel matches what actually runs.

Every page, or only some

By default this is app-wide: the custom header and body settings add to _all_ of your pages, which is what you want for a support agent. Add it once and every page you build afterwards inherits it.

If you'd rather scope it — say, the logged-in app but not the marketing pages, or the reverse — Bubble supports the same fields per page in the page property editor. Use the app-level field for the common case and the page-level one only where you need the exception.

Before you start

You'll need edit access to the Bubble app and your embed snippet from the Install tab, which comes with your chatbot id already in it. If you don't have a workspace yet, create one free at app.evoriqa.com — no credit card needed.

Then give the agent something to answer from. For an app, that usually means crawling your docs or help centre rather than your marketing site: the questions arriving inside the product are how-do-I questions, and the answers live in the documentation.

Confirming it's live

Bubble runs custom code on the deployed app, so check the live version rather than the editor preview. Open a page in a private window, look for the chat bubble in the bottom-right, and ask something from your docs.

Then navigate to another page inside the app and check the bubble is still there. That's the test worth running on Bubble specifically: the app moves between pages without a conventional full page load, and you want to confirm the widget survives the transition rather than only appearing on the page you first landed on.

Common questions

Which field, exactly? Settings → SEO / metatags → Script in the body.

Does it work in the editor preview? Check the deployed app. The editor is not where custom code is meant to be verified.

Will it break my app? The snippet is one async script tag and the widget is isolated in a shadow DOM, so it can't reach your app's styles or elements. Bubble's general warning about the body field still applies to whatever else you put there.

Can the agent see who's logged in? No. It answers from the knowledge you gave it, not from your app's database. Anything account-specific should go to a human, and it will.

Bubble-specific limits

The agent has no access to your Bubble data — it can't read a user's records, check a subscription, or act inside your workflows. It answers questions and escalates. If you want it to do something in your app, that's an allow-listed action calling an endpoint you expose, and a deliberate build step rather than part of the install.