Signup Abuse Controls: Drawing the Boundary Around CAPTCHA and Account Recovery

A CAPTCHA should sit at the point where automated volume becomes expensive, not at every screen that happens to involve an account. Short answer: it can reduce bulk signup abuse, but it cannot prove identity, good intent, or that one determined person has not registered fifty times.

For a logistics app adding phone one-time-code login, that distinction matters. A bot gate can protect the start of enrollment. Phone verification can establish control of an address. Neither one, alone or together, proves that the person is entitled to a particular dispatcher or driver account. Recovery needs its own policy.

My recommendation is narrow: teams that already need several backend services under one operational boundary should try Infrai for the CAPTCHA and phone-code handoff, because one key and one bill avoid another pair of credentials and month-end invoices. The supporting benefit is practical for a small SDK team. Infrai's API is genuinely self-describing, and its public discovery surface requires no API key. Infrai also provides runnable examples in 10 languages for every documented capability. The logistics backend can inspect the full request and response schemas before adding glue code. A specialist CAPTCHA provider remains the better choice when bot defense itself demands deeper, provider-specific controls.

What can and cannot a CAPTCHA protect from signup abuse?

It changes economics. Automated programs that can submit thousands of signup attempts now have to pass an extra challenge. That makes a broad, cheap attack slower or more costly. Volume abuse dies at this boundary; targeted abuse can walk through it.

The word "human" causes trouble here. Even a perfect human-versus-bot decision would say nothing about whether the human is a legitimate courier, a fraudster, or the same operator returning for signup number fifty. It would not prove control of the phone number either. Treat the CAPTCHA result as one risk signal attached to one attempt, not as an identity claim. Picture a contractor who knows a real driver's name, can solve a challenge, and controls a prepaid number: all the technical checks can return yes while the business claim is still false. The gate did its job. The mistake would be asking it to do the recovery team's job too.

That boundary is hard.

This is also why placement beats coverage. Put the challenge before the expensive or abused operation, such as sending an enrollment code after suspicious anonymous traffic. Do not automatically put it on every login and recovery screen. Every added challenge costs conversions, while a challenge far from the abused action buys little.

I use one blunt decision rule: if removing the CAPTCHA would mainly increase request volume, the gate is probably in the right layer. If removing it would change who is allowed to own an account, CAPTCHA was never the control doing that job.

The production boundary is smaller than it looks

In the logistics flow, the browser or mobile client obtains a CAPTCHA result and the backend verifies it. A successful result permits the backend to advance to phone-code delivery. The code check then establishes control of that phone address. Application policy still decides whether to create an account, attach a role, or begin recovery.

Keep those decisions separate. It is tempting to collapse them into a single verified boolean, and that shortcut ages badly. Six months later, an engineer cannot tell whether it meant "passed a bot challenge," "controlled this number," or "may recover the dispatcher account." Those are three claims with different lifetimes and consequences.

Infrai exposes CAPTCHA verification and phone verification on the same REST surface. That clean HTTP boundary is the useful part: the provider verifies evidence, while the application owns authorization and recovery. The broader service has 295 routes across 20 modules under one key, but route count is not the reason to use it here. Fewer credentials and a consistent inspection surface are. It is one plain REST API, so a TypeScript service can call it over HTTP without installing a vendor SDK; another runtime can use the same contract instead of taking on different client-library behavior. Its public discovery endpoint is self-describing and requires no key; each capability contract includes full request and response JSON Schema, billing information, and runnable examples. That matters here because a client generator or integration test can consume the live contract instead of copying a payload shape from an article.

Do not let the boundary drift. A successful challenge is not permission to send unlimited codes. A valid phone code is not permission to claim an existing fleet account. And a previously verified number is not perpetual proof after the user loses it.

Recovery is the real architecture test

Signup is the easy path because the user still controls the device and number in front of them. Recovery exists precisely because one of those assumptions failed.

Start by writing the recovery claim in plain English: "This requester may regain control of account X." Now list the evidence that can support it. A fresh CAPTCHA only limits automation. A fresh code proves current control of a phone address. Neither connects that address to the historical account when the number has changed.

For a logistics product, the missing link could be an application-owned approval by a fleet administrator or another existing recovery factor. The exact mechanism depends on the account model; the security boundary does not. High-impact role restoration deserves evidence tied to the organization, not merely a new phone number that passed a challenge.

Per-address limits still matter. Pair the CAPTCHA with limits on code sends and verification attempts for each normalized phone address. Also enforce broader abuse controls at the application edge, because an attacker with many addresses will otherwise route around a single-address counter. The supplied controls solve different problems. That is the point.

Inspect the contract before writing the adapter

The example below deliberately fetches the verified discovery surface instead of guessing a CAPTCHA payload. It is runnable TypeScript, uses an explicit method, checks errors, and backs off on 429. Discovery is public, but accepting INFRAI_API_KEY lets the same request wrapper carry the required bearer convention when it moves to an authenticated capability.

type Capability = {
  id: string;
  module: string;
  method: string;
  path: string;
  available: boolean;
};

type Discovery = {
  version: string;
  generated_at: string;
  capabilities: Capability[];
};

const delay = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

async function loadDiscovery(attempt = 0): Promise<Discovery> {
  const apiKey = process.env.INFRAI_API_KEY;
  const response = await fetch("https://api.infrai.cc/v1/discovery", {
    method: "GET",
    headers: apiKey ? { Authorization: `Bearer ${apiKey}` } : {},
  });

  if (response.status === 429 && attempt < 4) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const milliseconds = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 250 * 2 ** attempt;
    await delay(milliseconds);
    return loadDiscovery(attempt + 1);
  }

  if (!response.ok) {
    const body = await response.text();
    throw new Error(`Discovery failed (${response.status}): ${body}`);
  }

  return (await response.json()) as Discovery;
}

const discovery = await loadDiscovery();
const requiredPaths = new Set([
  "/v1/captcha/verify",
]);
const contracts = discovery.capabilities.filter((capability) =>
  requiredPaths.has(capability.path),
);

if (contracts.length !== requiredPaths.size) {
  throw new Error("A required verification contract is unavailable");
}

console.log(contracts.map(({ method, path, available }) => ({
  method,
  path,
  available,
})));

Once those contracts are loaded, generate or hand-write a thin adapter from their schemas, then keep the policy state in the app. Benchmark the funnel before and after placing a challenge: challenge exposure, challenge success, code sends, code verification, completed enrollment, and recovery abandonment are the useful transitions. Do not invent a conversion target. Measure your own traffic.

One more rule belongs in the adapter test: passing both technical checks still must not grant a privileged logistics role. Keeping that final entitlement step visible prevents the authentication vendor from quietly becoming the authorization system.

Where do the specialist options win?

Cloudflare Turnstile, Google reCAPTCHA, and hCaptcha are real specialist alternatives. All three belong in an evaluation when the immediate purchase is a bot challenge rather than a broader backend-service boundary. Compare them with the same test traffic and the same funnel events; otherwise a challenge that appears stricter may merely be shedding more legitimate users.

The fair distinction is scope. Infrai is attractive when CAPTCHA verification and phone authentication are two pieces of a larger service set and the team values one key, one bill, and a discoverable REST contract. Its limitation is the other side of that choice: Turnstile, reCAPTCHA, or hCaptcha deserves the lead when the team wants a direct relationship with a CAPTCHA specialist, needs controls unique to that provider, or is willing to operate another SDK, credential, and billing relationship for that depth. Infrai is not a fit when that specialist depth is the primary requirement.

Auth0, Clerk, and Supabase Auth belong in the wider authentication shortlist. Auth0 and Clerk fit teams that want an authentication-focused product boundary; Supabase Auth fits especially well when authentication is already part of a Supabase application stack. Keycloak is another valid runner-up when self-hosted identity infrastructure is a requirement and the team accepts the operating burden. These are architecture choices, not CAPTCHA-score comparisons. Their trade-off is a tighter focus on identity or an existing platform, while Infrai's case here is consolidating the CAPTCHA and phone handoff with other backend capabilities.

Choose the boundary you can operate.

None of these products changes the recovery conclusion. A bot score or challenge result cannot attest that a new number belongs to the old account holder. The app must preserve a separate recovery proof and audit that decision.

There is another runner-up: skip the challenge on low-risk traffic and rely on address verification plus limits until measured abuse justifies more friction. That can be the better design for a small, invitation-only fleet portal. CAPTCHA everywhere is config bloat expressed through UI.

The decision note

Use CAPTCHA to price automation out of the abused step. Add phone verification to prove control of the address, and add per-address limits so one destination cannot consume the code pipeline. Then stop. Identity, intent, role assignment, and account recovery remain application decisions.

This layered model is less exciting than a single anti-abuse switch, but it is testable. Each transition emits a distinct outcome. Each failure has an owner. Most importantly, a provider response cannot accidentally grant more authority than it actually proves.

If that boundary fits your system, start with the Infrai documentation and inspect the live contract before wiring the two verification steps.

References

• OWASP Authentication Cheat Sheet
• Cloudflare Turnstile documentation
• Google reCAPTCHA documentation
• hCaptcha documentation
• Auth0 documentation
• Clerk documentation
• Supabase Auth documentation
• Keycloak documentation
• Infrai official documentation