A contact form is supposed to be easy to reach. So is the lead form on your new Lovable app. The same open door that lets a prospective customer write to you also lets bots send junk into your inbox, database, and CRM.
Adding a CAPTCHA makes every visitor do extra work. But leaving the form alone means sorting through fake inquiries and wondering which message was real.
Today, ActiveLayer offers a guided spam-protection setup for Lovable forms. Copy our prompt into your existing project, let Lovable inspect its real submission paths, and review the server-side changes before you publish. This is a project-specific implementation, not a switch that automatically protects every app built with Lovable.
Start with an existing public form that a visitor can submit, such as a contact, inquiry, or lead form. The Lovable setup page provides a prompt for these forms and asks Lovable to report which ones it actually protected. Check that report for your app rather than assuming every form is covered.
Lovable must inspect each form’s fields and the path that actually handles its submission. A form that writes directly from the browser to a database needs a server handler for the protected write. An alternate endpoint or database policy must not let the same submission bypass the check. The guide tells Lovable to reuse your existing backend and keep the form’s design, validation, accessibility, and normal delivery path intact.
The integration guide directs Lovable to put the check in your app’s server handler after form validation and before saving a lead, sending an email, calling a CRM, or queuing other work. The handler sends mapped visitor content to ActiveLayer and reads the API’s is_spam verdict. When implemented as described, a clean verdict follows the existing submission path once. A spam verdict stops that path and returns a form error with the input preserved. The exact wording depends on your app. Review and test the generated changes to make sure your form follows this path.
This recipe does not cover login, account creation, password reset, payments, or uploads. An embedded form whose submission backend you cannot modify needs its own provider-side integration. Do not call it protected because its page happens to be inside a Lovable app.
Example: a blocked contact-form test in Lovable preview. Test data redacted; form design and message vary by project.
What happens when a check is unavailable
The published guide specifies a fail-open default for a timeout, service error, or exhausted allowance. It tells the implementer to continue the normal submission path, record the attempt as unchecked, and surface the problem to the owner. Unchecked is not a clean verdict: spam can get through while checks are unavailable. The guide handles a payload validation error differently, stopping the submission for repair while retaining the visitor’s input. If your app already has an explicitly stricter policy, the guide says to preserve it. Confirm the implemented behavior in your own project.
Why Lovable spam protection skips the CAPTCHA
A prospective customer should not have to solve a puzzle to ask for a quote. This setup calls ActiveLayer from your app’s server handler, not from a visible CAPTCHA widget. Your visitor keeps the form they came to fill out. If the check returns a spam verdict, they see your app’s form error rather than a challenge; if it returns a clean verdict, the form behaves as it did before.
Server-side also matters for the API key. It belongs in Lovable’s secure secret input or your connected backend’s secret manager, never in project chat, a browser variable, or frontend source. Your browser talks to your own submission handler; that handler talks to ActiveLayer. The guide asks the implementer to test not just the happy path but blocked verdicts, API failures, field mapping, and bypass routes. A preview test alone does not establish that the published app is protected.
Set it up in three steps
1. Paste the prompt into your existing Lovable project. Open the ActiveLayer for Lovable page, copy the full prompt, and give it to Lovable. It links to the implementation guide and asks Lovable to report which forms it found, how it mapped them, and any paths it cannot protect. This is not the ActiveLayer WordPress plugin.
2. Add your API key privately. Create a key in your ActiveLayer account. When Lovable requests ACTIVELAYER_API_KEY, use its secure secret input. Do not paste the key into chat. The guide requires a server-side credential check before setup is called complete.
3. Review, test, and publish. Inspect Lovable’s edits. Submit a normal form, simulate a blocked verdict and an API failure, and check that an old public route cannot write around the new handler. Test the published app after deployment, not just its preview. Ask Lovable to identify any form left unprotected. The server implementation depends on your project’s runtime and backend.
A note for agencies
If you build Lovable apps for clients, document coverage separately for each project. The same prompt is a starting point, not evidence that every client’s form uses the same handler. ActiveLayer’s pricing page lists unlimited sites on its plans; usage is counted in checks. Keep each project’s key in its server-side secret store and verify its live submission path before handing it over.
Pricing
New signups can start with 200 checks in total, a one-time allowance, with no credit card required. Existing Free accounts may have a different allowance shown in their account. Paid plans are available as your check volume grows. Check the current options on the pricing page.
Open your Lovable project, copy the prompt, and check the changes it makes to the forms that matter to you. The goal is specific: a server-side decision before a public inquiry becomes an email or lead, while legitimate visitors keep the form they came to use.
You block a spam domain. The next morning, the same messages arrive from a domain you have never seen, and the one after that is different again.
Throwaway domains are cheap. A spammer registers them in batches, burns through them and registers more. Blocking them one at a time is a queue that never gets shorter, and every entry you add is already out of date by the time you save it.
What those domains usually share is the mail infrastructure behind them. Different names, same mail servers. That part costs real money to move, so it changes far less often than the domain on the front.
Blocked Mail Servers is live. Block the mail host once and every domain running on it is covered, including the ones the spammer has not registered yet.
Every domain that can receive email publishes MX records: the hostnames of the mail servers that handle its mail. It is public, and anyone can look it up. A batch of throwaway domains pointed at the same provider all publish the same MX hostnames, because they are all using the same machines.
Blocked Mail Servers is a list of those hostnames. You enter them the way they appear in the records, like mail.spamhost.com, or you use a wildcard like *.spamhost.com to cover a whole provider in one line.
The difference from the list next to it is worth being clear about. Blocked Domains stops one domain. Blocked Mail Servers stops the machine behind it, and the next fifty domains that get pointed at it.
How the check runs
A submission arrives from an address like [email protected]. ActiveLayer looks up the MX records for throwaway123.xyz, takes the mail server hostnames that come back, and compares them against your list. Matching ignores capitalization, and wildcards are handled.
A match is final. The submission is marked as spam regardless of what every other signal says: no score, no threshold, no second opinion. You have already decided about that mail server, so nothing overrules you.
That is the whole point of the list, and it is also the reason to be careful about what goes on it.
One rule: do not block the big providers
The obvious mistake deserves naming out loud. Put Google’s mail servers on the list and you block every sender on Gmail. Put Microsoft’s on it and you block every sender on Outlook. Between them that is most of your real customers, and because a match is final, the filter will not save you from it.
The same mistake has a quieter version. A large shared host handles mail for thousands of unrelated businesses, so blocking its MX blocks all of them, including the supplier who has been emailing you for years.
This list is for the hosts that only ever send you spam. Look at what a hostname actually serves before you add it, and when you are not sure, add the one specific host rather than the wildcard.
Adding one to the list
1. Find the mail server
Take the sender domain off a spam submission you have already received, not one you are guessing at, and look up its MX records. Any MX lookup tool on the web does it in a second, and dig MX example.com does it from a terminal. What comes back is one or more hostnames.
2. Add the hostname
Open Spam Settings from the sidebar in app.activelayer.com. Blocked Mail Servers is the second list under Custom Block Lists, directly below Blocked Domains. Type the hostname, press Enter, and it becomes an entry. If a run of spam domains all point at the same provider, a single *.provider.com entry covers the ones you have seen and the ones you have not.
3. Save
Click Save Settings. It applies to submissions arriving from that point on. There is nothing to install, no code, and nothing changes for your visitors.
Where this one came from
A customer asked for it. Their spam was rotating sender domains faster than anyone could list them, and the mail servers behind those domains were not moving at all. They had already worked out where the real handle was. We built the setting that turns it.
If you are running into something ActiveLayer does not do yet, tell us. That is genuinely how this one happened.
Part of your spam settings
Blocked Mail Servers is one of five Custom Block Lists, second in the row, after Blocked Domains and ahead of Blocked Keywords, Blocked Email Addresses and Blocked IP Addresses. Nothing else changes. The AI check on the message, the sender signals and the behavioral signals all keep running exactly as they did, on our servers, where your visitors never see a puzzle and never solve one. What the new list adds is a hard override for the cases you have already identified yourself.
The list belongs to your account rather than to one project, so every project on the account is covered by the same entries. For an agency that is the whole point: block a mail server once and twenty client sites stop hearing from it, without touching twenty settings pages.
It is part of ActiveLayer on every plan, including the free one. There is no upgrade attached to it and no separate charge. The rest of the settings are covered in the documentation.
Open the last spam submission that got through, look up the sender domain’s mail server, and add it. The domain it came from will be gone by next week. The mail server will not.
Not sure whether a mail server is safe to block? Reach out. We read every message, and our team will help you get this running.
A spam check has a budget that most AI problems do not. Someone is sitting in front of a contact form with their finger on Send, and the answer has to arrive before they notice they are waiting. That is a few hundred milliseconds, total, including the network.
Large language models are very good at judging whether a message is junk. They are also built to write, which means they produce an answer one token at a time, and then something on our end has to read that text back and turn it into a number. For a filter that runs on every submission across thousands of sites, that is slow in exactly the place where slow is most visible.
So spam filters, ours included, lean on fast deterministic signals first and reach for the heavier model only where it earns its place. That works. It also means the sharpest judgment in the system is the part that is hardest to use everywhere.
ActiveLayer now runs Jev, a model built to make exactly that kind of call.
Jev comes from TypeSafe AI, a San Francisco company founded by Diogo Almeida, Erik Gafni and Sasha Sheng. It went into early access on 15 September 2026. TypeSafe calls it a System One model, and the defining property is easy to state: it does not write text.
You hand it a block of state, which can be an email, a log line, a form submission, a blob of JSON, along with a list of typed questions. It evaluates them in parallel and returns typed answers: a choice from a set you supplied, a score on a rubric you defined, or a probability on a yes or no question. Each answer carries its own calibrated confidence value.
Because the answer is drawn from a schema you provide rather than generated as a string, there is no output to parse and no format for the model to get wrong. It cannot invent a field, return prose where a number belongs, or wrap a verdict in an apology. TypeSafe reports end-to-end response times between 70 and 500 milliseconds.
The trade is real and worth stating plainly. Jev gives up the thing generative models are famous for. It cannot explain itself, cannot reason through several steps, and cannot handle a problem whose shape you have not decided in advance. It answers questions you already knew to ask.
Why that shape fits a spam check
A spam check is not an open question. It is a small, fixed set of decisions made under a latency budget, and the answer needs to be a number our code can threshold against, not a paragraph.
That is the same sentence twice. The description of what a System One model does and the description of what a spam filter needs are, for practical purposes, identical. Everything Jev gives up is something a spam check never wanted. Nobody needs the filter to explain itself in prose at the moment a form is submitted, and nothing downstream of the check can use a paragraph.
It also happens to be the case TypeSafe leads with. Their published evaluation sorted 19,528 emails into spam and legitimate mail with no training data at all, using a single yes or no question, and scored 96% accuracy. Writing a precise definition of what counted as spam took that to 98.3%, which matched a classifier trained on roughly 14,800 hand-labeled examples. Those are TypeSafe’s numbers, measured on their own harness and on email rather than on web form submissions.
Nothing had to be adapted to make the two meet. There was no adapter to write, no prompt to tune into returning clean JSON, no retry path for the times a model answers in the wrong format, and no parsing layer to maintain. You define the questions and the shape of the answers, and the answers come back in that shape. That is why the integration took a day rather than a sprint.
Anyone who has put a language model into a production path knows how much of that work there normally is, and how much of it is defensive: the schema validation, the repair prompts, the fallback for when a verdict arrives wrapped in an explanation nobody asked for. A model that cannot return a malformed answer deletes that entire category of code.
What went into our filter is a signal it did not have before, built on that model. A filter works with the signals available to it, and there is now one more.
Why five narrow questions beat one broad one
The speed is the headline. What matters more for a filter is that the questions are answered together.
A model that generates text answers one question at a time, so every extra question you want to ask is another wait you cannot afford inside a form submission. Jev evaluates the whole list in a single pass. One round trip comes back with five answers instead of one, which means asking five narrow questions costs the same wait as asking one broad one.
Narrow questions are also the ones a filter gets right. “Is this spam” is a judgment call with a lot packed into it. “Does this message contain a link to a domain unrelated to its text”, “is this written to evade a filter”, “would a real customer of this business plausibly send this” are smaller, sharper, and each comes back with its own confidence value that our code can weigh separately. That matters most on the messages that are nearly right. A real customer writing in a hurry and a spammer imitating one look similar under a single verdict, and different under five.
What this means for your forms
Your contact form now sits behind a filter with a sharper judgment available to it on the messages that are hardest to call. Obvious junk was never the difficult part. The difficult part is the message where a real customer writing badly and a spammer writing carefully look the same, and that is the part this is aimed at.
There is nothing to install, nothing to configure and no setting to go and find. It came with the service you already have.
Everything else works the way it did. The check runs on our servers, so your visitors never see a puzzle, never sort through pictures of traffic lights, and never have to prove anything. If our API cannot be reached, the check fails open and the submission goes through, because a form that silently stops working is a worse outcome than a piece of spam.
Jev sits inside that system, not in place of it. The deterministic signals still run and they still catch most of what arrives, which is what keeps the whole thing fast.
Get started
ActiveLayer is server-side spam protection for forms and comments. Install the plugin, paste your API key, and submissions start being checked. It works with the form and membership plugins you already use, and the documentation covers the REST API if you are protecting something we do not have an integration for.
Not sure whether your forms are catching what they should? Reach out. We read every message, and our team will help you get this running.
You install something, it works, and you end up mentioning it to someone. A client whose contact form is drowning. A developer in a Slack channel asking what people use instead of CAPTCHAs. It happens constantly, and nothing has ever come back to you for it.
Refer & Earn is live. Share your link, and when someone you invited connects their first site, you both get 50 extra spam checks.
Your invite link lives in Refer & Earn in your account. Copy it, or use the buttons for X, Threads, WhatsApp, LinkedIn, Facebook and email. The link remembers the invitation for 30 days, so someone who reads your message on a Tuesday and signs up three weeks later still counts.
2. They connect a site
They sign up, verify their email, and connect ActiveLayer on a site. That last part is the one that counts. A sign-up on its own does not earn anything, which is deliberate: the program rewards protecting a site, not filling in a form.
3. You both get 50
Fifty checks for you, fifty for them. Open either account once they have connected and both bonuses land.
What bonus checks are
They are a second meter, separate from your plan. Your account shows both: the plan allowance you already had, and your bonus checks underneath it.
Bonus checks are spent only after your plan’s own allowance runs out. So they sit there as a reserve, untouched, until you need them. They never expire. And they stay with you if you change plan, which matters if you are on the free plan now and move to Pro later.
The cap is ten rewarded referrals. Ten people who connect a site is 500 bonus checks, on top of whatever your plan gives you.
Separate from referrals, adding a payment method to your account earns 100 bonus checks. You are not charged for adding one, and those checks never expire either.
The rules, plainly
One site, one reward. If a site is already connected to another ActiveLayer account, it does not earn again. The check is on the site, not the account.
Ten referrals maximum. After that, further referrals stop earning.
Thirty days to sign up. The link remembers who sent them for a month.
The connection is what pays, not the sign-up. Someone who registers and never protects a site earns nobody anything.
Who to send it to, and when
Anyone who hands finished sites to other people. The reward is for someone else running their own ActiveLayer account, so a client who signs up and connects their own site counts, while ten sites under your own account do not. Agencies and freelancers do the first thing repeatedly, and ten of those is 500 checks back.
It also works if you have never referred anyone in your life. The card bonus is 100 checks for a thirty-second task you were probably going to do anyway.
An invite link is worth nothing sitting in your account. The ones that get used are the ones sent at the moment somebody has the problem.
Someone posts that their contact form is getting forty submissions a day and every one of them is junk. A client emails asking why the spam suddenly got worse. A developer asks what people use now, because they are tired of making visitors identify traffic lights. You were going to answer those anyway. Sending your link instead of just naming the plugin takes the same effort.
One thing worth saying when you send it: they get 50 too. That makes it a much easier message to write.
What 50 checks is worth
The free plan is 200 checks in total, one time. So a single referral adds a quarter of that, ten referrals adds two and a half times it, and the card adds half of it again. On a small site that is real breathing room.
On Pro it works differently. Your monthly allowance resets and the bonus sits underneath it, untouched, until a month comes along where you go over.
Get started
Open Refer & Earn in your account, copy your link, and send it to the next person who complains about form spam.
Questions about your site’s specific setup? Reach out. We read every message, and our team will help you get this running.
A message comes in through your contact form. It mentions dosages, a prescription, and a brand name for a painkiller. Is that spam?
If you run a roof repair company, almost certainly. If you run a pharmacy, that is a customer asking a normal question, and blocking it costs you a sale and probably a phone call complaining about your website.
ActiveLayer already reads a lot before it decides: the words, the links, the sender, the sending patterns and the behavioral signals. It does that well. What it had no way to know was the one thing you know without thinking: what your site is actually for. So a filter tuned to catch pharmaceutical spam across the whole web will sometimes catch a pharmacy.
Site Context is live. Tell the spam filter what your business does, and it judges against your site instead of against a generic idea of spam.
Site Context is a short description of your business that lives in your project’s settings, next to your site’s address. Two or three sentences: what you sell or do, who your customers are, and what your contact form legitimately receives.
The setting lives on the project. The same message can be a lead on one site and junk on another, and the filter now has enough to tell the difference. A bulk order inquiry is a real lead for a metal supplier and noise for a yoga studio. A message full of legal terminology belongs on a law firm’s form and nowhere near a bakery’s.
Leave it blank and nothing breaks. Your protection works exactly as it did before, judged against a general model of what spam looks like. Site Context is the difference between a filter that knows spam and a filter that knows your spam.
You do not have to write it yourself
A blank text box asking you to describe your own business is a small task that somehow takes twenty minutes. You know what your company does. Compressing it into three useful sentences is a different job.
So next to the field there are three buttons: ChatGPT, Claude and Perplexity. Each one opens that tool in a new tab with the prompt already written and your site’s address already in it. The assistant reads your site and writes the description, you copy it, and you paste it into the field. There is a Copy prompt button as well, if you use a different assistant. All four switch on once your Site URL is filled in, since that is what the prompt points at.
The prompt asks for the same three things every time: what the business sells or does, who its customers are, and what kinds of inquiries the contact form legitimately receives. Two or three sentences, under 500 characters, no preamble.
Nothing is connected. These are shortcuts that save you writing the prompt, not an integration. ActiveLayer does not call those tools, does not read anything back, and never sees the description until you paste it in and press Save. You see every word before it counts for anything.
Who this matters most for
It is worth setting on any site. It matters most on the ones where legitimate customers write things that look exactly like spam:
Medical, dental and pharmacy. Patients name drugs and conditions. So do spambots.
Legal and financial services. Real inquiries mention debt, settlements, claims and large sums, in the same vocabulary as the scams.
B2B and wholesale. A stranger asking about bulk pricing and lead times is your best lead of the week, and reads like a template.
Agencies and freelancers. Cold inquiries from people you have never met are the entire business model.
Anything regional or non-English. A form that mostly receives one language has an obvious boundary, and the filter has no way to know it unless you say so.
If you have ever fished a real customer out of your spam folder, this is the setting for you.
Setting it up takes about a minute
1. Open the project’s settings
In app.activelayer.com go to Projects and click the gear icon on that project’s row. If you are already inside the project, the Settings button is at the top right. Site Context is the only thing on that page.
2. Fill in the Site URL
On a WordPress project this appears on its own once the plugin connects. On a brand new project, or one running straight off the API, it starts empty and you type it in. It is worth doing first: the generate buttons stay switched off until it is there.
3. Write the description, or generate it
Up to 500 characters, with a counter so you can see where you are. Click Save. The rest of the plugin’s settings are covered in the documentation.
That is the whole setup. It applies from the moment you save, on that project, whether your submissions arrive through the WordPress plugin or straight from the API. Nothing to install, no code, and nothing changes for your visitors.
How to write a context that actually helps
The filter is not reading your marketing. It is looking for the boundary between a message that makes sense for you and one that does not. Concrete beats polished.
This works: “We are an independent pharmacy in Leeds. Customers ask about prescription collection, stock of specific medicines, dosage questions for products we sell, and delivery for housebound patients.”
Thirty seconds to write, and it does the job. It names what the business is, who writes in, and what a real message asks for. The prescription inquiry from the top of this post fits that description. A note about discount pharmaceuticals from an unknown sender does not.
This does not: “We are a leading provider of innovative solutions, committed to excellence and customer satisfaction.”
That describes nothing. It fits a metal supplier, a yoga studio and a spambot equally well, so it gives the filter no boundary to work with. If your description would look fine on someone else’s homepage, rewrite it.
Three habits worth having. Name the actual products or services, not the category. Say what a normal inquiry asks for. Mention your language or region if your form mostly receives one.
Available on every plan
Site Context is part of ActiveLayer for everyone, including the free plan. There is no upgrade attached to it and no separate charge. Set it per project, so an agency running twenty client sites can give each one its own description.
Open a project, write three sentences about your business, and save. From then on your site is what the filter compares against, not the average site on the internet.
Questions about your site’s specific setup? Reach out. We read every message, and our team will help you get this running.
Integration
Introducing ActiveLayer for FunnelKit
Written by:ActiveLayer TeamUpdated on
FunnelKit spam protection comes down to one thing: the opt-in form. It is built to be public. Anyone can land on your squeeze page, drop in an email, and become a lead. Bots count on it.
Fake leads do more than pad your numbers. They poison your list, skew your funnel stats, trip your automations, and burn send volume on inboxes that were never real. Every junk opt-in is another contact you scrub by hand, and another welcome sequence sent to nobody.
The usual answer is a CAPTCHA. Make every new lead prove they are human before they can opt in. The trouble is what that costs you. CAPTCHA challenges can interrupt form completion.
There is a better place to catch them.
Today, ActiveLayer ships native FunnelKit spam protection. Every opt-in is scored by AI on the server, before the lead is ever created. No puzzles. No checkboxes. Real subscribers never see a thing.
How FunnelKit spam protection works
1. The opt-in form
Your opt-in form is the one element of a funnel that has to stay open to strangers. That is the whole point of it, and it is exactly why bots target it. The fields are predictable, the URL is public, and a successful submit creates a real lead. A lead-capture form is a chokepoint. So we guard it.
When someone submits your opt-in, ActiveLayer scores it on the server in the same request. The check is synchronous, so the verdict comes back before FunnelKit writes the lead. A clean opt-in goes through untouched and the contact is created as normal. A spam opt-in is stopped cold: the form re-renders with an inline error, and no lead and no contact record are ever written.
A few details we cared about:
ActiveLayer runs after FunnelKit finishes its own validation, not before. If FunnelKit already rejected the submission, we don’t waste an API call second-guessing it.
It covers the opt-in step whether the form is embedded on the page or opens as a two-step pop-up. Same gate either way.
The blocked visitor sees a plain message, “Your submission was flagged as spam. Please try again or contact support.” No stack trace, no clue about what tripped it.
This integration protects FunnelKit lead-capture forms. Checkout is outside its scope; ActiveLayer does not gate a purchase.
2. The Submissions log
A spam filter you can’t see is a spam filter you can’t trust. If something blocks a real subscriber at your opt-in, that’s a lead you lost and never heard about. So ActiveLayer shows its work.
Every opt-in it processes lands in the Submissions log, blocked or clean. Open ActiveLayer → Submissions and each opt-in is right there. The provider column reads FunnelKit, with the opt-in’s form name beside it, so you can tell funnel opt-ins from your contact-form traffic at a glance. You see the verdict on each one. Open any entry for the score and the signals behind it.
Three things worth knowing:
Clean opt-ins are logged too, not just the blocks. You get the full picture of who tried to subscribe, not a one-sided list of rejects.
If a real subscriber ever gets caught, open the entry and report it. ActiveLayer retrains on that signal, so the same mistake gets less likely over time.
Every row shows the email submitted, so a blocked opt-in is an address you can actually look up, not an anonymous counter.
You audit the door instead of trusting it blindly. That’s the difference between a tool that works and a tool that says it does.
Why FunnelKit spam protection skips the CAPTCHA
An opt-in is a high-intent moment. Someone decided your offer is worth their email. That is the worst possible time to hand them a puzzle. CAPTCHA challenges can interrupt form completion.
ActiveLayer does its work entirely server-side. There is no challenge to render, no widget to load, no third party watching your visitors. The plugin drops a few hidden signal fields into the opt-in, invisible to visitors, and the verdict happens on our API. Your form looks exactly like it did yesterday.
Three properties matter here:
The check is synchronous and runs in the right order, after FunnelKit validates and before the lead exists. A blocked bot never becomes a contact in your list.
It fails open. If our API is slow or unreachable, the opt-in proceeds as if the check passed. ActiveLayer never blocks a real lead because we had a bad afternoon.
It does nothing until you connect a key, then it blocks on spam by default. No tracking-only half-measures, because letting a known bot through would create a junk contact you have to clean up.
Most spam tools start by suspecting your visitors. We start from the other direction. Never block a real lead. Catch the bots at the door.
FunnelKit spam protection in three steps
Setup is the same shape as every other ActiveLayer install.
1. Install the ActiveLayer plugin. It’s free on the WordPress plugin directory. Activate it like any other plugin.
2. Paste your API key. Sign up at app.activelayer.com for 200 free checks, no credit card. Paste the key into the plugin settings.
3. There is no step three. FunnelKit protection is on by default the moment your key connects. You’ll see FunnelKit marked Active under ActiveLayer → Integrations, with a toggle if you ever want to turn it off.
That’s the whole setup. The next bot that hits your opt-in gets stopped, and you don’t lift a finger.
A note for agencies
One ActiveLayer account covers every client funnel you run. Every plan includes unlimited sites, and you’re billed by check volume, not by how many installs you manage. Add a funnel site, drop in the key, done.
That’s the part our agency customers asked us to keep simple. We did.
Pricing
Same plans as everywhere else. Nothing new to buy for FunnelKit spam protection.
Free: 200 spam checks in total, unlimited sites, full API access, no credit card.
Pro: from $5/month for 5,000 checks, scaling up to 250,000. Unlimited sites. Email support.
Enterprise: from $149/month for 500,000+ checks, custom SLA, SSO, dedicated support.
One blocked spam run can mean hundreds of junk leads and a poisoned automation in an afternoon. The monthly fee costs less than the time you’d spend cleaning that up by hand.
Get started
Install ActiveLayer, connect your key, and FunnelKit spam protection is live by the time you finish your coffee. No CAPTCHA to configure, nothing to tune.
Already running ActiveLayer on your contact forms? Then there’s truly nothing to do. The same key already turns on FunnelKit spam protection, on by default, the moment you update.
Questions about your funnel’s specific setup? Reach out. We read every message, and our team will help you get this running.
MemberPress spam protection comes down to one page: the checkout. It stays open to strangers by design. Anyone can load your registration form, type an email, and create a WordPress account. Bots count on it.
Fake signups do more than pad your member count. They poison your member list, burn through coupon codes, and trip payment flows you then have to refund. Every junk account is another row you clean up by hand, and another welcome email sent to nobody.
The usual answer is a CAPTCHA. Make every new member prove they are human before they can join. The trouble is what that costs you. CAPTCHA challenges can interrupt form completion.
There is a better place to catch them.
Today, ActiveLayer ships native MemberPress spam protection. Every membership signup is scored by AI on the server, before the WordPress account and the membership are ever created. No puzzles. No checkboxes. Real members never see a thing.
How MemberPress spam protection works
1. The public signup form
Your membership checkout is the one page that has to stay open to strangers. That is the whole point of it, and it is exactly why bots target it. The fields are predictable, the URL is public, and a successful submit creates a real WordPress user. A registration form is a chokepoint. So we guard it.
When someone submits your signup form, ActiveLayer scores it on the server in the same request. The check is synchronous, so the verdict comes back before MemberPress creates the account. A clean signup goes through untouched and the membership activates as normal. A spam signup is stopped cold: the checkout re-renders with an inline error, and no WordPress user and no membership record are ever written.
It covers the classic form, Single Page Checkout, and ReadyLaunch. Free, free-trial, and fully discounted signups are checked by default. Paid signups require an opt-in setting.
2. The Submissions log
A spam filter you can’t see is a spam filter you can’t trust. If something blocks a real customer at your checkout, that’s a sale you lost and never heard about. So ActiveLayer shows its work.
Every signup it processes lands in the Submissions log, blocked or clean. Open ActiveLayer → Submissions and each membership signup is right there, tagged Member so you can tell registrations apart from your contact-form traffic at a glance. The provider column reads MemberPress. You see the verdict, the score, and the signals behind it.
Three things worth knowing:
Clean signups are logged too, not just the blocks. You get the full picture of who tried to join, not a one-sided list of rejects.
If a real member ever gets caught, open the entry and report it. ActiveLayer retrains on that signal, so the same mistake gets less likely over time.
Membership rows show the username or email, so a blocked signup is a name you can actually look up, not an anonymous counter.
You audit the door instead of trusting it blindly. That’s the difference between a tool that works and a tool that says it does.
Why MemberPress spam protection skips the CAPTCHA
A signup is the highest-intent moment you get. Someone decided your membership is worth their email and, often, their card. That is the worst possible time to hand them a puzzle. CAPTCHA challenges can interrupt form completion.
ActiveLayer does its work entirely server-side. There is no challenge to render, no widget to load, no third party watching your members. The plugin drops a few hidden signal fields into the checkout, invisible to visitors, and the verdict happens on our API. Your form looks exactly like it did yesterday.
Three properties matter here:
The check is synchronous and runs in the right order, after MemberPress validates and before the account exists. A blocked bot never becomes a row in your users table.
It fails open. If our API is slow or unreachable, the signup proceeds as if the check passed. ActiveLayer never blocks a legitimate registration because we had a bad afternoon.
It does nothing until you connect a key, then it blocks on spam by default. No tracking-only half-measures on account creation, because letting a known bot register would create a real account you have to clean up.
Most spam tools start by suspecting your visitors. We start from the other direction. Never block a real member. Catch the bots at the door.
MemberPress spam protection in three steps
Setup is the same shape as every other ActiveLayer install.
1. Install the ActiveLayer plugin. It’s free on the WordPress plugin directory. Activate it like any other plugin.
2. Paste your API key. Sign up at app.activelayer.com for 200 free checks, no credit card. Paste the key into the plugin settings.
3. There is no step three. MemberPress protection is on by default the moment your key connects. You’ll see MemberPress marked Active under ActiveLayer → Integrations, with a toggle if you ever want to turn it off.
That’s the whole setup. The next bot that hits your checkout gets stopped, and you don’t lift a finger.
A note for agencies
One ActiveLayer account covers every client site you run. Every plan includes unlimited sites, and you’re billed by check volume, not by how many installs you manage. Add a membership site, drop in the key, done.
That’s the part our agency customers asked us to keep simple. We did.
Pricing
Same plans as everywhere else. Nothing new to buy for MemberPress spam protection.
Free: 200 spam checks in total, unlimited sites, full API access, no credit card.
Pro: from $5/month for 5,000 checks, scaling up to 250,000. Unlimited sites. Email support.
Enterprise: from $149/month for 500,000+ checks, custom SLA, SSO, dedicated support.
One blocked spam ring can mean dozens of fake accounts and refund headaches in an afternoon. The monthly fee costs less than the time you’d spend cleaning that up by hand.
Get started
Install ActiveLayer, connect your key, and MemberPress spam protection is live by the time you finish your coffee. No CAPTCHA to configure, nothing to tune.
Already running ActiveLayer on your contact forms? Then there’s truly nothing to do. The same key already turns on MemberPress spam protection, on by default, the moment you update.
Questions about your membership site’s specific setup? Reach out. We read every message, and our team will help you get this running.
AffiliateWP spam protection comes down to one form: the affiliate registration page. It stays open to strangers by design. Anyone can load it, type a name and an email, and apply to your program. Bots count on it.
Fake affiliates do more than pad a list. They poison your referral stats, fish for coupon codes, and clutter the affiliate dashboard you use to run the program. Every junk application is another row you review by hand, and another approval queue you stop trusting.
The usual answer is a CAPTCHA. AffiliateWP ships a honeypot and one optional puzzle, and no native Akismet or CleanTalk hook on that form. So the bots that learned to read CAPTCHAs walk right through, and the people who hate them quietly give up.
There is a better place to catch them.
Today, ActiveLayer ships native spam protection for AffiliateWP. Every affiliate registration is scored by AI on the server, before the affiliate row and the WordPress user are ever created. No puzzles. No checkboxes. Real applicants never see a thing.
How ActiveLayer stops AffiliateWP registration spam
1. The public affiliate registration form
Your affiliate registration form is the one page that has to stay open to strangers. That is the whole point of it, and exactly why bots target it. The fields are predictable, the URL is public, and a successful submit creates a real affiliate and a real WordPress user. A registration form is a chokepoint. So we guard it.
When someone applies to your program, ActiveLayer scores the submission on the server in the same request. The check is synchronous, so the verdict comes back before AffiliateWP creates the account. A clean application goes through untouched and the affiliate is created as normal. A spam application is stopped cold: the form re-renders with an inline error, and no affiliate row and no WordPress user are ever written.
A few details we cared about:
ActiveLayer runs after AffiliateWP finishes its own validation, not before. If AffiliateWP already rejected the submission with its honeypot, its CAPTCHA, or a bad email, we don’t waste an API call second-guessing it.
It covers both render paths. Whether your registration form comes from the [affiliate_registration] shortcode or the block-based form, the same hidden signal fields and the same gate apply.
The blocked applicant sees a plain message, “Registration blocked: your submission was flagged as spam.” No stack trace, no clue about what tripped it.
And the scope, stated plainly: this release protects your public affiliate registration form, full stop. The affiliate login form, AffiliateWP add-on registration forms (WPForms, Gravity Forms, the other builders), and affiliates that get auto-registered when you let new WordPress users become affiliates automatically are out of scope for this release. We started at the front door on purpose. The registration form is where affiliate spam begins, and a bot that never gets an affiliate account never reaches your dashboard. This release does not score referral or coupon fraud, either. That is a separate problem from spam, and it belongs to AffiliateWP’s own roadmap.
2. The Submissions log
A spam filter you can’t see is a spam filter you can’t trust. If something blocks a real applicant on your registration form, that is a partner you lost and never heard about. So ActiveLayer shows its work.
Every registration it processes lands in the Submissions log, blocked or clean. Open ActiveLayer → Submissions and each affiliate application is right there. The form column reads Affiliate: followed by the username or email, because there is no named form to point at, just the one global registration flow. You see the verdict, the score, and the signals behind it.
Three things worth knowing:
Clean applications are logged alongside the blocks. You get the full picture of who tried to join, not a one-sided list of rejects.
If a real applicant ever gets caught, open the entry and report it. ActiveLayer retrains on that signal, so the same mistake gets less likely over time.
Each row carries the attempted username or email, so a blocked application is a name you can actually look up, not an anonymous counter.
You audit the door instead of trusting it blindly. That’s the difference between a tool that works and a tool that says it does.
Why we built this without CAPTCHAs
An affiliate application is a high-intent moment. Someone decided your program is worth their time. That is a poor time to hand them a puzzle. Drop the CAPTCHA and you keep the applicants it was quietly costing you, the ones who give up rather than count traffic lights.
ActiveLayer does its work entirely server-side. There is no challenge to render, no widget to load, no third party watching your applicants. The plugin drops a few hidden signal fields into the registration form, invisible to visitors, and the verdict happens on our API. Your form looks exactly like it did yesterday.
Three properties matter here:
The check is synchronous and runs in the right order, after AffiliateWP validates and before the affiliate exists. A blocked bot never becomes a row in your affiliates table or your users table.
It fails open. If our API is slow or unreachable, the application proceeds as if the check passed. ActiveLayer never blocks a legitimate signup because we had a bad afternoon.
It does nothing until you connect a key, then it blocks on spam by default. No tracking-only half-measures on account creation, because letting a known bot register would create a real affiliate you then have to clean up.
Most spam tools start by suspecting your visitors. We start from the other direction. Never block a real applicant. Catch the bots at the door.
AffiliateWP registration spam, gone in three steps
Setup is the same shape as every other ActiveLayer install.
1. Install the ActiveLayer plugin. It’s free on the WordPress plugin directory. Activate it like any other plugin.
2. Paste your API key. Sign up at app.activelayer.com for 200 free checks, no credit card. Paste the key into the plugin settings.
3. There is no step three. AffiliateWP protection is on by default the moment your key connects. You’ll see AffiliateWP marked Active under ActiveLayer → Integrations, with a single toggle if you ever want to turn it off.
That’s the whole setup. The next bot that applies gets stopped, and you don’t lift a finger.
A note for agencies
One ActiveLayer account covers every client site you run. Every plan includes unlimited sites, and you’re billed by check volume, not by how many installs you manage. Add an affiliate program, drop in the key, done.
That’s the part our agency customers asked us to keep simple. We did.
Pricing
Same plans as everywhere else. Nothing new to buy for AffiliateWP.
Free: 200 spam checks in total, unlimited sites, full API access, no credit card.
Pro: from $5/month for 5,000 checks, scaling up to 250,000. Unlimited sites. Email support.
Enterprise: from $149/month for 500,000+ checks, custom SLA, SSO, dedicated support.
One blocked spam run can mean dozens of fake affiliates and a poisoned referral report in an afternoon. The monthly fee costs less than the hours you’d spend cleaning that up by hand.
Get started
Install ActiveLayer, connect your key, and AffiliateWP spam protection is live by the time you finish your coffee. No CAPTCHA to configure, nothing to tune.
Already running ActiveLayer on your contact forms? Then there’s truly nothing to do. The same key already turns on AffiliateWP spam protection, on by default, the moment you update.
Questions about your affiliate program’s specific setup? Reach out. We read every message, and our team will help you get this running.
WS Form spam protection comes down to one moment: what happens after someone hits submit. The entry gets written to your database. Your form actions fire. Notification emails go out, webhooks ping your CRM, and your team gets paged about a lead that was never real.
That is the part that costs you. A junk entry is one more row to sift through, one more email you learn to ignore, one more integration call you pay for. The forms doing the damage are the everyday ones: contact forms, lead forms, signup forms, the payment form on your pricing page. The ones you actually need open to the public.
The usual answer is a CAPTCHA bolted onto every form. It nags the real people filling out your forms, and the bots that learned to read puzzles submit anyway. You lose the visitor and keep the spam.
There is a better place to catch them.
Today, ActiveLayer ships native WS Form spam protection. Every submission is scored by AI on the server, before WS Form saves the entry or runs a single action. No puzzles. No checkboxes. Real visitors never see a thing.
How ActiveLayer stops WS Form spam
1. Every submission, checked before it’s saved
Your public forms are the one place that has to stay open to strangers. That is the whole point of them, and exactly why bots fill them. The fields are predictable, the URL is public, and a successful submit becomes a stored entry that triggers your actions. So we guard the submission itself.
ActiveLayer scores each submission on the server in the same request. The check is synchronous, and it runs inside WS Form’s own validation, before the entry is written. A clean submission goes through untouched and your actions run as normal. A spam submission is stopped cold: the form returns an inline error, and no entry is saved and no action ever fires.
A few details we cared about:
It runs before the entry is saved and before any action runs. A blocked bot never lands in your entry list, never sends you a notification email, and never reaches the webhook or CRM on the other end of your form.
It covers the spoofable path too. WS Form’s public action post mode can be poked directly, skipping conditional logic but still saving the entry and running Send Email. ActiveLayer checks that path exactly like a normal submit, so there is no side door.
The blocked visitor sees one plain message, “Your submission was flagged as spam. Please try again or contact support.” No stack trace, no clue about what tripped it.
You also decide which forms get checked. Protection is on for every form the moment your key connects, and each form carries its own switch. Open a form, go to the Spam tab, and you’ll find an ActiveLayer fieldset with a single Enable checkbox. Turn it off for a form and that form alone stops being checked. The same per-form toggle is mirrored on the ActiveLayer Integrations screen, so you can manage every form from one list. And to be exact about scope: draft saves are never checked, a form you’ve disabled passes through, and if your API key is missing the form submits normally.
2. The Submissions log
A spam filter you can’t see is a spam filter you can’t trust. If a real customer gets blocked on your contact form, that is a lead you lost and never heard about. So ActiveLayer shows its work.
Every submission it processes lands in the Submissions log, blocked or clean. Open ActiveLayer → Submissions and each WS Form entry is right there. The form column reads the form’s own label, the same name you gave it in the editor, so a blocked row tells you which form took the hit. You see the verdict, the score, and the signals behind it.
Three things worth knowing:
Clean submissions are logged alongside the blocks. You get the full picture of what every form received, not a one-sided list of rejects.
If a real submission ever gets caught, open the entry and report it. ActiveLayer retrains on that signal, so the same mistake gets less likely over time.
Each row carries the form’s label, so you know exactly which of your forms a bot was hammering, not an anonymous counter.
You audit the door instead of trusting it blindly. That’s the difference between a tool that works and a tool that says it does.
WS Form spam protection without CAPTCHAs
Someone filling out your form already decided to reach you. That is a poor time to hand them a puzzle. Drop the CAPTCHA and you keep the people it was quietly costing you, the ones who give up rather than count traffic lights on your contact page.
ActiveLayer does its work entirely server-side. There is no challenge to render, no widget to load, no third party watching the people who use your forms. The plugin drops a few hidden signal fields into the form, invisible to visitors, and the verdict happens on our API. Your form looks exactly like it did yesterday.
Three properties matter here:
The check is synchronous and runs in the right order, inside WS Form’s validation and before the entry exists. A blocked bot never becomes a stored entry, and your actions never fire on it.
It fails open. If our API is slow or unreachable, the submission proceeds as if the check passed. ActiveLayer never blocks a legitimate submission because we had a bad afternoon.
It does nothing until you connect a key, then it blocks on spam by default. You stay in control per form, but you don’t have to switch anything on form by form to get protected.
Most spam tools start by suspecting your visitors. We start from the other direction. Never block a real submission. Catch the bots before the entry is saved.
WS Form spam protection in three steps
Setup is the same shape as every other ActiveLayer install.
1. Install the ActiveLayer plugin. It’s free on the WordPress plugin directory. Activate it like any other plugin. WS Form Lite or Pro, either edition works.
2. Paste your API key. Sign up at app.activelayer.com for 200 free checks, no credit card. Paste the key into the plugin settings.
3. There is no step three. Protection is on by default the moment your key connects. You’ll see WS Form marked Active under ActiveLayer → Integrations, with a per-form toggle if you ever want to skip a specific form.
That’s the whole setup. The next bot that submits gets stopped, and you don’t lift a finger.
A note for agencies
One ActiveLayer account covers WS Form spam protection on every client site you run. Every plan includes unlimited sites, and you’re billed by check volume, not by how many installs you manage. Build a client’s forms, drop in the key, done. Need one form left open for a partner feed? Flip its toggle off and the rest stay guarded.
That’s the part our agency customers asked us to keep simple. We did.
Pricing
Same plans as everywhere else. Nothing new to buy for WS Form.
Free: 200 spam checks in total, unlimited sites, full API access, no credit card.
Pro: from $5/month for 5,000 checks, scaling up to 250,000. Unlimited sites. Email support.
Enterprise: from $149/month for 500,000+ checks, custom SLA, SSO, dedicated support.
One unblocked spam run can mean a hundred junk entries, a flood of notification emails, and a CRM full of names you’ll never sell to. The monthly fee costs less than the hours you’d spend cleaning that up by hand.
Get started with WS Form
Install ActiveLayer, connect your key, and WS Form protection is live by the time you finish your coffee. No CAPTCHA to configure, nothing to tune.
Already running ActiveLayer on your other forms? Then there’s truly nothing to do. The same key already turns on WS Form spam protection, on by default for every form, the moment you update.
Questions about your forms’ specific setup? Reach out. We read every message, and our team will help you get this running.
Run a BuddyBoss community with open registration and the bots find you before the members do. BuddyBoss registration spam rarely looks dramatic at first: a fake profile here, a keyword-stuffed bio there, until the member directory your real members scroll through starts reading like a link farm.
On a community that charges for membership, that’s not cosmetic. People are paying to be in the room. Every junk profile, and every strange message that arrives after a fake account activates, chips away at the thing they pay for: the sense that the room is real. And cleanup falls on you, one suspicious account at a time, hoping none of the ones you delete were customers.
The standard fix is to bolt a CAPTCHA onto the signup form. We think that solves the wrong problem. CAPTCHA challenges can interrupt form completion, and your registration page is the worst place to absorb that hit: it’s where your sales page, your course launch, and your members’ invites all send people.
So we pointed ActiveLayer at it.
Today, ActiveLayer ships native spam protection for BuddyBoss Platform. One plugin, one API key, and an AI check that runs server-side on every signup, before the pending account is ever created. It’s on by default the moment your key connects. No puzzles. No checkboxes.
How ActiveLayer stops BuddyBoss registration spam
1. The public signup form
BuddyBoss Platform puts your registration form at /register/, and that URL is no secret. Bots crawl for it the way they crawl for login pages. Every signup that slips through becomes a pending account, then an activated member: a profile in your directory, standing in your community, reach into the inboxes of people who actually pay to be there.
ActiveLayer now gates that form. The check is synchronous and server-side: it runs after BuddyBoss Platform’s own validation passes and before the pending signup record is created, so no activation email ever goes out. On a spam verdict, the form re-renders with an inline error next to the email field: “Registration blocked: your submission was flagged as spam.” The account never exists. It’s the same check our customers already run on contact forms and WooCommerce registrations, pointed at the signup surface bots love most.
A few details we cared about:
First error wins. If BuddyBoss’s own validation already rejected the signup (a bad email, a missing required field), ActiveLayer never calls the API. You don’t burn a check on a submission that was failing anyway.
BuddyBoss Platform generates usernames from the email address, so there’s no username box for us to read. The integration falls back to the profile’s Name field automatically. Nothing to map, nothing to configure.
Coverage is scoped to public signups, on purpose. Activity streams, private messages, group updates, bbPress, and signups made through the BuddyBoss App’s REST endpoint are out of scope for this release. The signup form is the choke point: an account that’s never created can’t spam anything.
Everything else about registration stays BuddyBoss’s: your form design, your profile fields, your activation flow. We just decide, quietly, whether the account should exist.
2. The Submissions log
Any tool that blocks signups invisibly raises a fair question: what exactly is it blocking? A community is a business, and a false positive at the door is a customer you never meet. You shouldn’t have to take our verdicts on faith.
So every signup attempt the integration checks lands in your Submissions log, blocked and clean alike. Blocked signups are labelled Member, followed by the username or email that tried to register, and the provider column reads BuddyBoss. It’s a receipt for your front door: who knocked, what we decided.
Three details worth knowing:
Akismet doesn’t check BuddyBoss signups, so there’s no overlap. Keep it on comment duty if it’s serving you well.
CleanTalk hooks the same signup validation step. Both plugins can run together; whichever flags the spam first wins.
Clean signups are logged alongside the blocked ones. If you ever suspect a real member was turned away, you check the log instead of wondering.
We’d rather you audit the verdicts than trust them blindly.
Why we block BuddyBoss registration spam without CAPTCHAs
Every CAPTCHA you remove is some percentage of completions back in your pocket. CAPTCHA challenges can interrupt form completion, and a community signup is a high-intent moment you usually paid to create: someone clicked through from a sales page, a podcast mention, a member’s invite. A traffic-light puzzle is a strange way to say welcome.
ActiveLayer is entirely server-side. No challenge renders in your visitor’s browser, and no new JavaScript ships for this integration; the only additions are hidden signal fields, injected through BuddyBoss’s own form hooks. When the form is submitted, your site sends the signup’s email, name, IP, and user agent, plus those behavioral and environment signals, to the ActiveLayer API, and waits for the verdict before the signup goes through.
Three properties matter for a community:
The check runs in the right order: after BuddyBoss has validated the form, before the pending signup is stored or an activation email goes out. A blocked bot doesn’t become a moderation task. It becomes nothing.
If our API is unreachable, times out, or returns an error, the signup proceeds. ActiveLayer never blocks a legitimate registration because we had a bad afternoon.
Registration is the one surface where a spam verdict always blocks. There’s no log-and-allow mode here, because letting a known spammer register doesn’t create a log entry. It creates a real account.
Most spam tools optimize for “block more spam” and accept blocking more humans as the cost. We start from the other direction. Never block a real member. Catch the bots at the door.
Spam-free BuddyBoss in three steps
Setup is the same shape as every other ActiveLayer install, minus a step. Install the plugin, add your key. That’s the list.
1. Install the ActiveLayer plugin. Free in the WordPress plugin directory. Activate it on the site running BuddyBoss Platform.
2. Paste your API key. Sign up at app.activelayer.com for 200 free checks (no credit card). Paste the key into the plugin settings.
3. There is no step three. Signup protection is on by default once your key is connected. Open Integrations under the ActiveLayer menu and the BuddyBoss row will already read Active, with a toggle right there if you ever want to pause it.
That’s the whole setup. ActiveLayer detects which community platform a site runs and only shows the toggle that applies. And if you’re on free BuddyPress rather than BuddyBoss Platform, the same release ships a dedicated integration for that too.
A note for agencies
If you build or maintain BuddyBoss communities for clients, one ActiveLayer account covers all of them. Every plan (Free, Pro, Enterprise) includes unlimited sites. You’re billed by spam-check volume across your portfolio, not by site count.
That’s the part our agency customers asked us to keep simple. We did.
Pricing
Same plans as everywhere else. Nothing new for BuddyBoss.
Free: 200 spam checks (one-time), unlimited sites, full API access, no credit card.
Pro: from $5/month for 5,000 checks, scaling up to 250,000. Unlimited sites. Email support.
Enterprise: from $149/month for 500,000+ checks, custom SLA, SSO, dedicated support.
For most communities, Pro is the right starting tier. Signup attempts are a trickle next to a store’s checkout traffic, and the monthly fee is less than the moderation hour it replaces. If you’d rather watch it work first, the free 200 checks are enough to see what’s been knocking.
Get started
Install ActiveLayer, connect your key, and put a working gate on your community’s front door. Your members never meet a CAPTCHA. The bots never meet your members.
Already running ActiveLayer on your contact forms? Update to the latest ActiveLayer plugin (version 1.3.0 or newer) and you’re done: BuddyBoss signup protection turns on by default once an API key is connected. Open Integrations under the ActiveLayer menu if you’d like to see the Active badge for yourself.
Questions about your community’s specific setup? Reach out. We read every message, and our team will help you get this running.
The cf_ob_info cookie provides information on: The HTTP Status Code returned by the origin web server. The Ray ID of the original failed request. The data center serving the traffic
session
__cfseq
Sequence rules uses cookies to track the order of requests a user has made and the time between requests and makes them available via Cloudflare Rules. This allows you to write rules that match valid or invalid sequences. The specific cookies used to validate sequences are called sequence cookies.
session
cf_clearance
Whether a CAPTCHA or Javascript challenge has been solved.
session
_cfuvid
The _cfuvid cookie is only set when a site uses this option in a Rate Limiting Rule, and is only used to allow the Cloudflare WAF to distinguish individual users who share the same IP address.
session
__cflb
When enabling session affinity with Cloudflare Load Balancer, Cloudflare sets a __cflb cookie with a unique value on the first response to the requesting client. Cloudflare routes future requests to the same origin, optimizing network resource usage. In the event of a failover, Cloudflare sets a new __cflb cookie to direct future requests to the failover pool.
session
cf_chl_rc_i
These cookies are for internal use which allows Cloudflare to identify production issues on clients.
session
__cf_bm
Cloudflare's bot products identify and mitigate automated traffic to protect your site from bad bots. Cloudflare places the __cf_bm cookie on End User devices that access Customer sites that are protected by Bot Management or Bot Fight Mode. The __cf_bm cookie is necessary for the proper functioning of these bot solutions.
session
__cfruid
Used by the content network, Cloudflare, to identify trusted web traffic.
session
cf_chl_rc_m
These cookies are for internal use which allows Cloudflare to identify production issues on clients.
session
cf_chl_rc_ni
These cookies are for internal use which allows Cloudflare to identify production issues on clients.
session
__cfwaitingroom
The __cfwaitingroom cookie is only used to track visitors that access a waiting room enabled host and path combination for a zone. Visitors using a browser that does not accept cookies cannot visit the host and path combination while the waiting room is active.
session
cf_use_ob
The cf_use_ob cookie informs Cloudflare to fetch the requested resource from the Always Online cache on the designated port. Applicable values are: 0, 80, and 443. The cf_ob_info and cf_use_ob cookies are persistent cookies that expire after 30 seconds.
session
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author_url
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author
Used to track the user across multiple sessions.
Session
Google Tag Manager simplifies the management of marketing tags on your website without code changes.
Name
Description
Duration
td
Registers statistical data on users' behaviour on the website. Used for internal analytics by the website operator.
session
cookiePreferences
Registers cookie preferences of a user
2 years
These cookies are used for managing login functionality on this website.
Name
Description
Duration
wordpress_test_cookie
Used to determine if cookies are enabled.
Session
wordpress_sec
Used to track the user across multiple sessions.
15 days
wordpress_logged_in
Used to store logged-in users.
Persistent
WPForms is a user-friendly WordPress plugin for creating custom forms with drag-and-drop functionality.
Name
Description
Duration
wpfuuid
Used to track user interactions with forms.
11 years
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_ga_
ID used to identify users
2 years
_gid
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
