Every vendor page tells you what the product does. This one tells you where it does not help, where the signal does not exist, and where it stops on purpose. You should know all of it before you pay, not after.
These are real problems. They are not my problem, and I would rather say so now.
If your problem is junk traffic you do not want to pay to serve, use Cloudflare Turnstile. It is free, it runs at the network edge, and I am not going to beat network level defense from an API call. That is a real recommendation, not a setup.
Use an email validation service. Bad addresses cost you money today, and they cost it whether or not a human typed them. Buy that before you buy this.
Use MFA. A stolen password used by a real person is a human, and I will score it as one. Different problem, different layer.
Use a fraud vendor. I answer whether a visitor behaves like a human, not whether a transaction is legitimate.
No interaction, no signal. Tuning cannot create data that was never there.
Server to server calls, webhooks, native mobile requests without a webview. There is no interaction to observe, so there is nothing for me to score. If your traffic never renders a page, this is the wrong tool and no amount of tuning changes that.
No script, no signals. On our own signup we treat this as a case to let through rather than reject, because a real developer with an aggressive privacy extension is far more common than a bot that fetched the page first. Your integration should make the same choice.
Someone who lands and submits within a second or two leaves almost nothing to score. You get a low confidence number and you should treat it as low confidence, not as a verdict.
Limits of the approach itself, not of this implementation.
If someone pays a person to fill in your form, that person is a human and I will say so. Behavior tells you what something is, never what it intends. No behavioral system solves this, including the expensive ones.
Any client side signal can eventually be synthesized by someone patient and well resourced. What this raises is the cost of attacking you, not an absolute wall. Anyone selling you the wall is selling you something.
People using screen readers or navigating without a mouse behave differently from mouse users by definition. useHUMA recognizes this case and adjusts instead of penalizing it, and it is the area I watch most closely, because the cost of getting it wrong is blocking someone who did nothing wrong.
Both of these are design decisions. Plan for them.
You have zero bot protection for that window. That is the actual price of failing open and I am not going to hide it behind the word resilient. One thing to be precise about: an outage on my side only stays out of your way if your integration lets the request through when the call fails. That part is yours to write. It is a timeout and a catch, and it is what our own signup does. If you block on a failed call instead, my outage becomes your outage.
The API returns 429 with the reset date and verification stops until the window resets. You never get a surprise invoice, and you also do not get verification. Handle a 429 the same way you handle an outage.
This is built and supported by one developer. If you adopt it now you are among the first teams running it in production, which means you get me directly on email and you also carry the risk that comes with being early.
The honest version of the bus factor question: this is one HTTP call, there is no data to migrate out, and if I disappeared you would delete the call and be back to whatever you did before. That is architecture, not a promise, which is why I am willing to put it in writing.
No accuracy or false positive rate. I do not have a benchmark I would defend in public, and at my traffic volume any number I printed here would be invented. When I have one, I will publish the method next to the number so you can argue with both.
No customer names. Telling the internet who runs bot detection tells attackers exactly where to test. I will not name a customer even when it would help me, and especially not now, when it would help me most.
I also do not publish which signals matter or how they are weighted. Here is the full reasoning for that one, including what I publish instead.
You do not have to take any of this from me. Run it in shadow mode for two weeks: call verify, log the confidence, and act on nothing. Then go look at the signups you already know were fake and see where they landed.
One practical note, because otherwise you would hit it: the free trial is 14 days, so a two week shadow run uses all of it and leaves you no time to read the data. Email me before it runs out and I will extend it. That is a one line change on my side and I would rather you evaluate this properly than rush it.
Every response includes the threshold your verdict was compared against, so you are never guessing which number made the decision.
If your fake signups come from automation hitting a real page, and you do not want to put a puzzle in front of the humans, then yes. If you are not seeing abuse yet, do not buy this yet. Come back when the fake signups show up.
Start free trial →