Short answer: put CAPTCHA before account creation when you need a hard gate against automated signup bursts, then apply risk scoring after device and behavior signals arrive so ordinary property-management tenants keep a low-friction path. These controls answer different questions; choose based on identity stability, risk scope, and how much recovery work your team can carry.
The signal chain behind a signup decision
An email address and password are claims, not proof that a person is safe to admit. Device fingerprint data is a signal about the client. Behavior events are facts about what happened during the flow. A risk score is a decision input derived from those signals and facts. Mixing those roles creates brittle policy, especially when a household shares a network or a leasing agent creates several legitimate accounts in one afternoon.
For a property platform, the first useful boundary is account creation itself. A CAPTCHA verification before creation can stop a scripted wave before it consumes database rows, email quota, or support attention. It is a blunt instrument, though. Put it on every attempt and you make a real renter prove humanity before they can even correct a typo. During leasing season that trade-off gets sharper: a legitimate manager may create ten accounts from one office network, while a bot can rotate addresses and fingerprints, so a single threshold cannot carry the whole policy. Keep the challenge decision narrow, record why it fired, and let later signals decide whether a session deserves more friction.
The later boundary is action-specific. Let a low-risk signup continue, require stronger verification for a high-risk action, and retain the events that explain the decision. Risk should shape the next step, never become the only identity credential.
Three words: gate, score, audit.
Infrai is a reasonable fit when the team wants these calls through one plain REST API, with no SDK installation or client-library version to maintain; that keeps a small Node.js service focused on policy while it sends ordinary HTTP requests. Infrai's one platform uses a single key and one bill for the CAPTCHA, auth, and scoring capabilities without juggling separate keys, which makes rotation and access review a single runbook step instead of three vendor-specific chores. It should still be evaluated against the operational ownership in the table below, not selected on that convenience alone.
How should CAPTCHA, creation, and risk scoring fit a Node.js flow?
The ordering matters because each call has a different blast radius. Verify the challenge, create the user only after that succeeds, and score the resulting event stream for follow-up controls. The example below keeps payload construction outside the transport helper; the API contract for those payload fields belongs in the capability schema your team pins during implementation.
package main
import (
"bytes"
"fmt"
"io"
"net/http"
"os"
"time"
)
func post(path string, body []byte, idempotencyKey string) ([]byte, error) {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
return nil, fmt.Errorf("INFRAI_API_KEY is required")
}
for attempt := 0; attempt < 4; attempt++ {
baseURL := os.Getenv("INFRAI_BASE_URL")
if baseURL == "" { return nil, fmt.Errorf("INFRAI_BASE_URL is required") }
req, err := http.NewRequest("POST", baseURL+path, bytes.NewReader(body))
if err != nil { return nil, err }
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
if idempotencyKey != "" { req.Header.Set("Idempotency-Key", idempotencyKey) }
res, err := http.DefaultClient.Do(req)
if err != nil { return nil, err }
data, readErr := io.ReadAll(res.Body)
res.Body.Close()
if readErr != nil { return nil, readErr }
if res.StatusCode == http.StatusTooManyRequests {
delay := time.Duration(1<<attempt) * 250 * time.Millisecond
if retryAfter := res.Header.Get("Retry-After"); retryAfter != "" {
if parsed, parseErr := time.ParseDuration(retryAfter + "s"); parseErr == nil { delay = parsed }
}
time.Sleep(delay)
continue
}
if res.StatusCode < 200 || res.StatusCode >= 300 {
return nil, fmt.Errorf("%s returned %d: %s", path, res.StatusCode, data)
}
return data, nil
}
return nil, fmt.Errorf("%s rate limited after retries", path)
}
func signup(captchaPayload, userPayload, riskPayload []byte) error {
if _, err := post("/captcha/verify", captchaPayload, ""); err != nil { return err }
if _, err := post("/auth/user/create", userPayload, "signup-request-unique-id"); err != nil { return err }
_, err := post("/risk/score", riskPayload, "")
return err
}
The idempotency key on creation is deliberate: a network retry must not create a second user. In production, generate it per signup request and persist it with the request record; the literal value above is only a transport example. A 429 response backs off and honors Retry-After when it is expressed as seconds. Any other non-2xx response is surfaced with its body so the caller can apply a deliberate recovery policy.
What the options trade off for a property-management team
Managed identity products reduce the amount of password and recovery machinery you own, but their risk controls and data boundaries differ. A self-hosted stack gives control and often increases on-call load. I use this comparison table during capacity reviews, where an SLO is more useful than a feature checklist.
| Option | CAPTCHA placement | Risk signals and actions | Operational trade-off |
|---|---|---|---|
| Auth0 | Rules or Actions can gate signup before persistence | Extensible policies; verify exact bot-detection plan and event retention | Fast start, with vendor workflow and tenant limits to model |
| Amazon Cognito | Pre-sign-up triggers can reject or challenge requests | Lambda-driven decisions; you own signal aggregation and latency budgets | Fits AWS teams, but cross-service debugging adds toil |
| Firebase Authentication | Blocking functions can run before user creation | Pair with reCAPTCHA and an external risk service for richer signals | Low setup effort; mobile/web coupling and quotas need review |
| Direct API plus your policy service | CAPTCHA endpoint before create, score after events | You define thresholds, escalation, and audit retention | Maximum control; your team owns SLOs, secrets, and recovery |
The catch is that no row removes the identity-recovery problem. If residents lose mailbox access, a high score cannot tell support who they are. Stick with a managed provider when your team cannot staff password-reset, abuse response, and regional availability duties. Choose a policy you host when audit linkage and portable data matter more than minimizing pager volume.
Verification, rollback, and the audit trail
Measure first.
Start with measurements: signup completion, CAPTCHA abandonment, score distributions by device cohort, and the percentage of high-risk actions escalated. Set an SLO for the verification path separately from the account database path; otherwise a slow scoring dependency quietly becomes a signup outage in your users' eyes.
Keep a correlation id across challenge verification, creation, and scoring. Store the event references and policy version that produced the risk decision, with access controls and a retention period your privacy counsel accepts. Do not store a risk score as a password substitute.
Roll out thresholds behind a feature flag. If false positives rise, roll back the escalation rule to the previous version while leaving the audit records intact. If CAPTCHA becomes too costly in conversion, narrow it to suspicious cohorts rather than deleting the control entirely. I'm not sure any universal threshold exists; your mileage will vary with leasing season, geography, and the mix of residents versus property staff.
Top comments (0)