Protect a signup flow

Place SignupBear at the correct point in account creation.

Recommended sequence

1. Validate the signup payload in your backend.
2. Call POST /v1/check with the normalized email.
3. Check both the HTTP status and response status.
4. Enforce recommended_action.
5. Create the account only after an allowed decision.
6. Store request_id, policy_version, and the action in your audit event.

export async function registerUser(input) {
  const response = await fetch("https://signupbear.com/v1/check", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.SIGNUPBEAR_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ email: input.email }),
    signal: AbortSignal.timeout(3000),
  });

  const result = await response.json();

  if (!response.ok || result.status === "failed") {
    return applySignupRiskFallback({
      requestId: result.request_id,
      errorCode: result.error?.code,
    });
  }

  if (result.recommended_action === "block") {
    return { accepted: false, requestId: result.request_id };
  }

  return createAccount(input, {
    signupBearRequestId: result.request_id,
    signupBearAction: result.recommended_action,
  });
}

Choose a failure policy

Decide what your application does on timeout, HTTP 429, or HTTP 500 before launching. Consumer products often add another verification step; higher-risk systems may reject or queue the signup.

Do not retry every failed request automatically. A retry after HTTP 429 still consumes capacity only when it is accepted, but repeated retries increase load and delay your signup flow.

User-facing errors

Keep rejection copy generic. Detection reason codes are for your server logs and operations, not for showing an attacker which rule matched.