Block Disposable Emails in Bubble

To block disposable emails in Bubble, add one POST call in the API Connector, feed it your signup form's email input, and branch the workflow on the action field that comes back: allow proceeds, warn shows a message, and block terminates the workflow before Sign the user up ever runs. It takes about fifteen minutes in the editor, works on any Bubble plan, and is built to fail open, so a check that cannot complete never costs you a signup. This guide walks the API Connector path click by click, then covers the drop-in snippet and backend workflows.

Why do Bubble apps attract fake signups?

Because a Bubble app makes fake accounts unusually expensive, and abusers unusually cheap. Your app runs on usage-priced infrastructure: every signup consumes workload units, database rows, scheduled workflows, and emails, and if your product offers a free tier, trial credits, or metered AI features, each fake account converts your paid capacity directly into someone else's free lunch. One person with a throwaway provider is an unlimited supply of fresh identities, returning for a new trial as often as your form allows. The supply side never runs short: as of the September 2026 State of Disposable Email report, the dataset behind this guide tracked 217,847 disposable domains, with 10,223 new ones arriving in a single 36 day window, and 9,971 of those new domains passed live MX validation on report day. Bubble form spam looks deliverable because, on signup day, it usually is. Blocking it at the form is the cheapest point of intervention you will ever get.

How do you set up the API Connector to check emails?

Install the API Connector plugin if it is not already in your app (Plugins, Add plugins, API Connector, by Bubble), then add a new API and configure it exactly like this:

Setting	Value
API name	IsItDisposable
Authentication	Private key in header
Key name	Authorization
Key value	Bearer sk_live_your_secret_key
Call name	Check Email
Use as	Action
Data type	JSON
Method and endpoint	POST https://api.isitdisposable.com/v1/check
Header	Content-Type: application/json
Body	{"email":""}

Two details matter. Use your secret key here, the one that starts with sk_; because the call runs with private key authentication, Bubble keeps it on the server side and it is never exposed to the browser. And in the body, the angle brackets around <email> turn it into a call parameter: untick its Private checkbox so your workflows can supply the address dynamically.

To initialize, put a real test address in the email parameter, [email protected] works well since Mailinator is the canonical disposable provider and you can see exactly what the dataset knows about it on its public domain page, then click Initialize call. Bubble will show the returned fields; confirm action came back as text and disposable and relay as yes/no, then save. That is the whole bubble API Connector tutorial portion; the rest is ordinary workflow logic.

How do you use the action field in a signup workflow?

On your signup page, edit the workflow behind the Sign up button so the check runs first and everything else branches on its result, in this order:

1. Plugins, IsItDisposable - Check Email, with email set to your email input's value.
2. Element Actions, Show, on a hidden group holding your soft message ("Heads up: this address looks temporary. Use one you will keep to make sure you can recover your account."), with Only when set to Result of step 1's action is "warn".
3. Element Actions, Show, on your error text ("Please use a permanent email address. Temporary addresses stop working, and you would lose access."), with Only when set to Result of step 1's action is "block".
4. Navigation, Terminate this workflow, with Only when set to Result of step 1's action is "block".
5. Account, Sign the user up, exactly as you had it.

Order is the mechanism: Bubble runs steps in sequence, and Terminate this workflow halts everything after it, so a block verdict shows your message and stops before the account exists, a warn verdict shows the nudge and proceeds, and allow, the overwhelming majority of real signups, flows through untouched. If you would rather branch on raw signals, the result also carries disposable and relay as yes/no fields, but action arrives with your dashboard policy, edge cases included, pre-decided.

What happens if the API is unreachable?

Your signup goes through, by design, and the promise has two layers in Bubble terms. First, the service itself degrades into permission rather than error: an exhausted quota or an overloaded moment returns a normal response with action set to "allow", so none of your Only when conditions fire and the workflow simply proceeds to Sign the user up. Second, for the rare hard failure where the call cannot complete at all, add Bubble's page-level event An unhandled error occurs and point it at the same Sign the user up action, so even a network-level failure resolves to a created account rather than a stuck form. The check exists to protect your list; the moment it cannot do its job, the correct behavior is to step aside, and this wiring makes that automatic.

Can you use the drop-in snippet instead?

Yes, if your plan allows custom code. The snippet is one tag, generated in your dashboard with your publishable pk_ key, mode, and message already baked in:

<script src="https://cdn.isitdisposable.com/v1/snippet.js"
  data-key="pk_live_your_publishable_key"
  data-mode="warn"
  async></script>

Paste it into Settings, SEO / metatags, in the header script box to cover the whole app, into a single page's HTML header for one page, or into an HTML element next to your form. It attaches to email inputs and applies your configured action as the visitor types, with no workflow logic at all. The honest caveat: on Bubble's current pricing, custom headers and the HTML element are paid plan features, Starter and up, while the API Connector path above works on every plan including free, which is why the connector leads this guide.

What about backend workflows?

If signups reach your app server side, through your app's API, a bulk import, or a scheduled backend workflow, the same Check Email action is available there too. Add it as the first step, then put Only when Result of step 1's action is not "block" on the Create account step (or the downstream steps that grant anything valuable). Same call, same verdict, same policy, enforced in a context no browser can bypass.

Which path should you choose?

Path	Where it runs	Effort	Plan requirement	What it can block
API Connector workflow	Bubble's server, inside your workflow	About 15 minutes	Any plan, including free	Account creation itself, with full control of messages and branching
Drop-in snippet	Visitor's browser, at the form	Paste one tag	Paid plan (custom code)	Bad addresses before submission, with your configured message
Backend workflow	Bubble's server, no browser involved	Reuses the same call	Paid plan (backend workflows)	Server side and bulk signups that never touch a page

For most Bubble apps the answer is the connector workflow, with the snippet as polish if your plan includes custom code.

Should you block relay addresses like Apple Hide My Email?

No. Relay and alias services, Apple Hide My Email, Firefox Relay, SimpleLogin, addy.io, DuckDuckGo Email Protection, Proton aliases, forward to a real person's permanent inbox, and the people behind them are privacy-conscious, often paying users. The check reports relay as its own signal and the default policy treats it as warn, never block; leave it that way and let your warn branch do the gentle work. The full reasoning is in the relay section of The Complete Guide to Disposable Email Detection, and it is the link to send anyone who proposes a blanket block.

One last framing note before you ship it: the fake signups you fail to catch do not hurt your Gmail reputation, mailbox providers judge you on how their own users treat your mail. The cost shows up in your workload units, your trial infrastructure, and later at your email service provider, when the dead throwaways on your list hard bounce in a batch and platforms like Mailchimp or SendGrid open a list quality review. The check behind this guide is isitdisposable.com: a live dataset of 217,847 disposable domains per the September report, drawn from multiple upstream sources, MX-validated and refreshed daily, answering in the one API call you just wired. The free plan covers 250 lookups a month and the 14-day full-access trial needs no credit card, which is plenty to watch a Bubble app's real signup traffic sort itself into allow, warn, and block.