Why Bubble apps need an AI chatbot
Bubble is where most modern no-code SaaS gets built. The platform now claims more than four million creators, and the typical Bubble app is a real product with paying users: a marketplace, a CRM, an internal tool, a vertical SaaS for a specific industry. Those products generate the same support questions that traditional SaaS does, but the founders running them rarely have a support team. A founder shipped the app solo on Bubble, picked up the first paying customers, and now their inbox fills up with the same five onboarding questions every week.
A chatbot solves the wrong problem if you treat it as a help desk replacement. It solves the right problem if you treat it as a knowledge layer in front of your help docs, your pricing page, and your feature pages, so the visitor who would otherwise email "how do I export to CSV?" gets the answer at 2am without you waking up. That is the unlock for a Bubble app: a content-trained chatbot that reads your own pages, replies in your own voice, and never invents pricing tiers that do not exist.
The wrinkle on Bubble specifically is the economics. Bubble's pricing model is built around Workload Units (WUs), which meter every database query, workflow execution, and API call your app runs. Plugins that route chatbot traffic through Bubble workflows consume WUs per message, and at scale this compounds. A script-tag widget that runs entirely in the visitor's browser, talks directly to an external service, and never touches a Bubble workflow does not consume WUs at all. That distinction matters once your bot starts handling real volume.
What "AI chatbot for Bubble" specifically means
When operators search "ai chatbot for bubble," they mean one of three things, and the right install path depends on which one.
The first meaning is the public-facing marketing site that explains the SaaS, built on Bubble's responsive page engine. Pricing pages, landing pages, feature pages. Visitor traffic, anonymous, conversion-focused. The chatbot here helps prospects qualify themselves before signing up. This is the most common case, and it maps almost exactly onto a Webflow or WordPress install: paste one snippet, the bubble appears on every page, done.
The second meaning is the authenticated product itself, where a logged-in user lives inside the Bubble app and might ask a question about how to use a specific feature. The chatbot here is product help, in-app, often scoped to specific pages. This needs the page-level install path (HTML element approach), so the bot only appears in the app shell after login and can be configured per page.
The third meaning is a chatbot built INTO the Bubble app as a feature for end users, where the bot is part of the product the founder is selling. That is a different problem (you are building a chatbot product, not adding one to your site) and usually points toward a Bubble plugin or the API connector talking to OpenAI directly. ChatRaj is not the right pick for that case; we cover it briefly in the "when ChatRaj is not the right call" section below.
For meanings one and two, ChatRaj's script-tag install works the same way it does on any modern web platform. The difference is just where you paste the snippet.
ChatRaj on Bubble: install paths
There are two clean install paths on Bubble, and they cover roughly 95 percent of cases. Both bypass the Bubble plugin marketplace, both avoid touching a workflow, and both leave Workload Units untouched.
Path A is the app-wide install via Settings, SEO/metatags, Script in the body. One snippet, applied to every page in your Bubble app. Best for marketing sites and apps where you want the chatbot bubble visible everywhere.
Path B is the per-page install via an HTML element dropped onto a specific page. The snippet lives inside the HTML element, so the bubble only appears on that specific page. Best for in-app help that should only show up on certain logged-in pages.
You pick one. Mixing both creates duplicate widgets, which the ChatRaj loader detects and warns about, but it is still better to keep one or the other.
Path A: Settings > SEO/metatags (per-page or app-wide)
Open your Bubble editor. Click Settings in the left sidebar (the gear icon), then click the SEO/metatags tab at the top. Scroll down past the Page title and Description fields. You will see a section labeled "Script/meta tags in header" and another labeled "Script in the body."
The header section accepts <script>, <meta>, and <link> tags only. Anything else gets pushed into the body anyway by the browser's auto-repair logic, so do not bother trying to paste arbitrary HTML there. For the ChatRaj widget loader, the body slot is the right home: it loads after your Bubble app shell renders, never blocks the page from being interactive, and behaves exactly like the equivalent slot on Webflow or WordPress.
Paste the ChatRaj snippet into the "Script in the body" box:
<script async src="https://chatraj.com/widget.js" data-bot-id="YOUR_BOT_ID"></script>
Click Save. The snippet is now staged in the editor but not yet live on your deployed app. To push it live, hit Deploy current version to live (the blue button in the top-right of the editor). Within a few seconds, the live version of your Bubble app shows a floating chat bubble in the bottom-right corner of every page. Open an incognito window, visit your live app, click the bubble. Send a test message. The bot answers.
A note on scope: the Settings, SEO/metatags fields apply app-wide by default, but Bubble also lets you override the same fields at the page level. Every page in the editor has its own SEO/metatags panel inside the page's property editor. If you set a page-level value, it wins over the app-wide value for that page. Useful if you want the bubble everywhere EXCEPT on, say, your checkout page where you would rather visitors not get distracted.
Path B: HTML element on a specific page
If you want the bot to appear only on one page (typical for in-app help where the bubble should not show on the marketing site or vice versa), use the HTML element approach.
Open the target page in the Bubble editor. Drag an HTML element from the left-side element panel onto the page. Position it somewhere out of the way (top of the page, off-canvas, anywhere; the script tag itself does not render visibly). Open the HTML element's property editor and paste the same ChatRaj snippet into the HTML content field.
Save the page. Deploy. The chat bubble now appears only on that specific page. If a visitor navigates to a different page in your Bubble app, the bubble disappears because the HTML element is not present on that page.
This is the right pattern for: a single help-center page inside your app, a specific landing page you want to A/B test the bot on, a customer dashboard page where the bot should only appear post-login, or a page-by-page rollout where you want to test on one page before going app-wide.
The HTML element approach gives you more granular control than the Settings approach, at the cost of having to add the element to every page where you want the bot. For app-wide deployments, Path A is faster. For targeted deployments, Path B is cleaner.
What ChatRaj reads from a Bubble app
Training the bot on your Bubble app means pointing ChatRaj at your live app URL and letting the crawler index your public pages. Bubble apps render server-side enough that the crawler reads the actual content (titles, body copy, pricing tables, feature descriptions) and ingests it the same way it would for a static site.
Pages behind authentication are not crawled, which is correct behavior: the bot should not train on data that is meant to be private to logged-in users. If your Bubble app has a public marketing site at the root domain and a logged-in product on a subdomain or a specific path prefix, the bot trains on the public marketing pages and ignores the rest.
For data living in the Bubble database (user records, transaction records, product entries that are gated by privacy rules), the bot does not have access to that data and cannot answer questions about it. That is by design: a content-trained chatbot is not a database query engine. If you need the bot to answer "what is the status of order 12345?", that is a different product category (a customer-data chatbot wired into your database via API), and ChatRaj is not the right pick for it.
For data that lives in your Bubble app as public content on public pages (the about page, the pricing page, blog posts, help articles, feature descriptions), the crawler picks all of it up and the bot answers questions about it confidently.
Lead capture for Bubble-built SaaS waitlists
A common Bubble use case is the pre-launch waitlist site: a founder built an MVP on Bubble, has not opened signups yet, and uses the site to collect emails from prospects. The chatbot fits this pattern well because the bot can qualify prospects (answer questions about what the product does, when it launches, what it costs) and capture the email at the end of the conversation.
ChatRaj's lead capture works without any Bubble workflow: when the bot detects buying intent in a conversation, it asks for an email, captures it, and either sends it to your CSV export, fires a webhook, or pushes to your CRM via Zapier (planned). The captured email does not flow back into Bubble's database (we are not modifying your data model), but it does flow to wherever you tell ChatRaj to send it.
For founders who want the captured email to land in their Bubble database for follow-up automations, the cleanest pattern is to point the ChatRaj webhook at a Bubble API workflow endpoint. The webhook fires when a lead is captured, hits your Bubble backend workflow, and creates a record in your Bubble database. This DOES consume one workflow run per lead (so it does cost a small number of WUs), but the cost is tiny compared to running the entire chatbot through Bubble workflows.
Founders running a waitlist on Bubble often layer the chatbot with a typical Bubble email-capture form: the form lives on the hero section for visitors who already know they want in, and the chatbot handles the rest of the funnel for visitors who need to ask a question or two before committing. Both flows write to the same Bubble data type via different routes, and the bot picks up the slack on the prospects who would have bounced from a static landing page.
Bubble pricing gotchas (Workload Units, Personal vs Pro)
Two pricing gotchas trip up first-time Bubble operators when adding any third-party widget.
The first gotcha is the free plan. Bubble's free tier is real but trial-only: you can build in the editor, you cannot deploy to a live custom domain, and your app cannot accept real visitor traffic. Any chatbot widget you paste into a free-tier app will not reach real users because the live version is not publicly accessible. To publish a live app, you need at least the Starter plan ($29/mo with annual billing, $35/mo monthly as of May 2026). That is a Bubble cost, not a ChatRaj cost.
The second gotcha is Workload Units. Bubble meters everything that runs on its servers (database reads, workflow executions, API calls, page loads) and charges per Workload Unit consumed. Plans include monthly allocations from 50,000 WUs (Free) to 175,000 WUs (Starter) to higher tiers. Overage costs $0.30 per 1,000 WUs.
The implication for chatbots: anything that runs a Bubble workflow per chat message consumes WUs. Marketplace chatbot plugins that route chat messages through a workflow (to log the conversation, to fire a notification, to update a record) consume WUs in proportion to chat volume. At a hundred conversations per day, a workflow-based chatbot is using maybe 3,000 to 6,000 WUs daily, or 90,000 to 180,000 WUs monthly. That alone can blow past the Starter allocation.
The ChatRaj widget runs entirely in the visitor's browser and talks to chatraj.com directly. Zero Bubble workflows are involved. Zero Workload Units are consumed. The only WU cost is if you wire the lead-capture webhook back into Bubble (one workflow run per captured lead), which is a tiny fraction of the chat volume. Most operators will not notice the WU impact at all because it is rounding error inside their normal app traffic.
ChatRaj vs Bubble plugins (chatbot plugins in the Bubble Marketplace)
The Bubble plugin marketplace has a handful of chatbot plugins. They generally fall into two categories: thin wrappers around OpenAI's API (you bring your own API key, the plugin gives you a UI element to drop on a page) and full chatbot widgets from third-party vendors (Tidio, Crisp, others) that install via a plugin instead of a script tag.
The OpenAI wrapper plugins are appealing because they give you total control over the bot's behavior, but they push every prompt and response through Bubble workflows. That means WU consumption per message, latency added by the Bubble workflow runtime, and a maintenance burden if OpenAI changes its API surface. They also require you to handle training data, conversation history, and rate limiting yourself, which is not trivial.
The third-party widget plugins are convenient (install from the marketplace, add a plugin element to a page) but they generally exist because the vendor wanted Bubble distribution, not because the plugin offers anything beyond the script-tag install. The plugin model adds a wrapper around the same widget you would get from pasting the script tag, and the wrapper exists mostly to give the vendor a Bubble Marketplace listing.
ChatRaj does not maintain a Bubble plugin. The script-tag install is the install. We do not need a Marketplace listing because Bubble already gives you two clean places to paste a script tag (Settings, SEO/metatags or an HTML element). Skipping the plugin saves you a Marketplace install, removes a layer of indirection, and keeps the widget update path entirely on our side (we ship widget changes by updating widget.js, with no plugin version bump or Marketplace approval cycle needed).
There is also a quieter benefit to skipping the plugin route: your Bubble app's plugin list stays clean. Every plugin you install gets evaluated by Bubble's runtime on every page load, and a long plugin list adds milliseconds of initialization overhead before your app becomes interactive. Operators with twenty-plus plugins notice this. Keeping the chatbot off the plugin list means one less thing to evaluate at startup.
When ChatRaj is NOT the right call (need workflow trigger integration)
A few honest signals that ChatRaj is the wrong product for your specific Bubble use case.
Your bot needs to read or write data in the Bubble database. ChatRaj is content-trained and reads public HTML. It does not connect to Bubble's Data API and cannot see user records, transaction records, or any data behind privacy rules. If you need the bot to answer "what is my account balance?" or "list my last five orders," you need a chatbot that integrates with your Bubble database via API. ChatRaj is not that product.
Your bot needs to trigger Bubble workflows mid-conversation. The ChatRaj widget runs in the visitor's browser and talks to chatraj.com. It does not call back into Bubble workflows during a conversation. Lead-capture webhooks can fire a Bubble API workflow once at the end of a conversation, but the bot cannot dispatch a workflow per message. If your use case is "ask the bot to schedule a meeting, and the bot should create a meeting record in my Bubble database," that needs a different product.
Your Bubble app is a chatbot product. If you are building a SaaS where the chatbot is the product (a customer-facing chatbot you sell to your own customers), you want a chatbot infrastructure layer, not a chatbot widget. ChatRaj is for adding a chatbot TO a website. Building a chatbot product on Bubble is a different category entirely, and you will be happier with the Bubble API connector pointed at OpenAI or with a dedicated infrastructure layer.
For everyone else (the marketing site for your Bubble SaaS, the help center for your Bubble app, the public landing page for your no-code product) the script-tag install is fast, free to try, and never touches Workload Units. The Bubble plan you already have is the only Bubble cost involved, and the ChatRaj free tier covers the testing phase before you ever commit a dollar to the chatbot side.