Bot detection for Indian websites and apps 

DetectBT is invisible bot detection for Indian websites and web apps: a script in your page checks the browser, your server verifies a signed token, and by default only a verified bot or a forged token is refused. The Free plan includes every detection signal and needs no card.

Use it on the routes bots target most: sign-up, login, OTP requests, referral claims and checkout.

Which bot problems should Indian apps watch for?

The patterns are the same worldwide, but some cost more for products that rely on phone numbers, joining bonuses and cashback:

• OTP and SMS abuse. Bots hammer your “send OTP” endpoint and you pay for every message. Some attacks aim at premium-rate or foreign numbers on purpose.
• Fake sign-ups for bonuses and referrals. Scripts open accounts in bulk to claim joining bonuses, referral credits or wallet cashback.
• Promo and coupon farming. Automated accounts redeem first-order offers again and again.
• Credential stuffing. Leaked username and password pairs are tried against your login at scale.
• Checkout abuse. Scripted carts hoard limited stock or test stolen cards.

How does DetectBT work?

1. Add one script tag with your publishable key. It is about 23 KB gzipped, sets no cookies, and works only on the sites you allow for that key.
2. Before a protected request, the page calls DetectBT.getToken({ action: "otp" }), which mints a fresh token at submit, and sends it in an x-detectbt-token header.
3. Your server verifies it with POST /verify and your secret key, and gets a verdict: human, fraud, bot, unknown, verified_agent or unscored.

Behind the scenes DetectBT checks eight signal families, from automation and stealth-plugin tells to engine coherence, rendering, a hidden challenge and a per-site device key. Scoring happens on our server; the weights never reach the browser. There is no puzzle to solve, which matters when many customers are on phones and slow connections. No package is needed: the integration is a script tag and one HTTPS call from your server.

How do I protect an OTP endpoint?

Put the check before the message is sent:

// POST /otp/send: a sensitive route. verifyDetectBT, detectbtIsUp, verifip
// and claimOnce are the helpers from the fake sign-ups guide.
const token = req.headers["x-detectbt-token"];
const bt = token ? await verifyDetectBT(token) : null;
if (bt?.valid === false) return res.sendStatus(403);              // forged, other site, expired
if (!token && (await detectbtIsUp())) return res.sendStatus(403); // missing token
if (bt?.valid && (bt.verdict === "bot" || !(await claimOnce(bt.jti, bt.exp)))) {
  return res.sendStatus(403);                                      // a bot, or a token used twice
}

const phone = await verifip(`/v1/phone?phone=${encodeURIComponent(req.body.phone)}`);
if (phone && !phone.valid) return res.status(400).json({ error: "invalid_phone" });
if (phone && phone.country_code !== "IN") {
  return res.status(400).json({ error: "unsupported_country" });  // if you only send to +91
}
await sendOtp(phone?.phone ?? req.body.phone);

The helpers are in the fake sign-ups guide. Each token is accepted once, so a script cannot replay one token to send hundreds of messages, and a missing token is refused while DetectBT is up. VerifIP's phone check validates the number, its country, line type and VoIP status before you pay for the message.

Will it block real customers?

It is designed not to. DetectBT is non-blocking by default: the recommended handling refuses only a verified bot or a provably bad token. Everything else, including unknown verdicts, reaches your code flagged, and you decide. If DetectBT is slow or unreachable, requests go through. Over your plan, after a 10% grace, evaluations pass through unscored and are never billed. Only signals measured on real users are scored; new checks are logged first.

On routes you treat as sensitive, such as OTP, sign-up and payment, a missing token is refused, so give customers whose browser blocked the script another way through, such as a support contact.

What about shared mobile addresses?

DetectBT judges the browser, not the IP address, so a customer who shares a carrier-grade NAT address with an abuser is not marked as a bot for it. Two parts of the decision table do look at the address, so test them on mobile traffic before you rely on them:

• Recent bots. If you implement the table's recent-bot rule (block a missing or expired token from a client that produced a verified bot in the last 10 minutes), remember that on a shared mobile address that client may be someone else.
• IP binding. With expected_ip, a token minted on another /24 (IPv4) or /64 (IPv6) fails with ip_mismatch, and a phone's public address can change between page load and submit, for example when it moves between Wi-Fi and mobile data.

Which devices has DetectBT been tested on?

Our September 2026 lab ran on Windows 11 and macOS against a local worker, not production traffic. Real, unautomated browsers on Mac, iOS and Android simulators all came back human, and DetectBT blocked all 13 default and lightly evaded automation setups. Real phones and real Safari on iOS are still being measured, so run it on your own traffic, flagged but not blocking, before you enforce. DetectBT runs in web browsers, including mobile browsers; it does not cover native apps. The setups it does not catch yet are listed on the DetectBT page.

How much does it cost?

Prices are listed in US dollars, and every plan includes every detection signal. You are billed one evaluation per page load, and bot verdicts are never billed. Add VerifIP for IP, email, phone and URL checks, and both together cost about 20% less than buying them separately. Full details are on pricing.

Can collection wait for consent?

Yes. Add data-consent="false" to the script tag and nothing is collected until you call DetectBT.grantConsent(). DetectBT sets no cookies, and its device key is per site and deleted with the site's data.

How do I start?

Sign up free, add the script to one route and log the verdicts before you enforce anything. The fake sign-ups and free trial abuse guides have worked examples. Questions: contact@hextner.com.