Rate limiting on public portal endpoints

Every unauthenticated portal action carries a per-IP limit sized to what a real customer would do.

What it is

Per-endpoint IP rate limits across the public surface: sign-in attempts, approvals, colour picks, password setting, form submission, contract signing, contract reads, invoice payment starts and the billing list endpoints, each with its own budget per minute.

Also called: brute force · someone hammering my link · abuse protection

See it
Rate limiting on public portal endpoints
🔒ridgelinepostframe.com/project/portal550
Barndominium
Framing · on schedule
No UI; show the 429 message 'Too many attempts, try again in a minute'. src/lib/rateLimit.ts callers. Sample data — no customer information appears here.
How it works
  1. 1Each route calls the shared IP limiter with its own key, budget and window
  2. 2Exceeding it returns a 429 with a plain message
  3. 3Budgets are sized per action, from a handful of sign-in or approve attempts up to sixty reads
Why we built it

The portal is public by design: the link is the credential and there is no login session to throttle against, so a shared or leaked link could be hammered without limit. Every public endpoint has a request budget. Sign-in gets a tighter one than the rest, because it is the single place where a password can be guessed.

The problem
  • Unauthenticated endpoints open to automated abuse
  • Password guessing on protected links
Sound familiar?
What you get
Public endpoints stay public without being open to abuse
Limits are sized so a real customer never hits one

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →