Anti-abuse

QueueUp runs every signup through a fixed pipeline of checks. Each one is independent, opt-in (with sensible defaults), and configured per waitlist. The order is fixed, chosen so cheap checks reject obvious abuse before the expensive ones run.

The pipeline

Origin allowlist

The origin allowlist is the single hard requirement on every waitlist: the widget can’t submit from a domain that isn’t on the list. Configured under Setup → Origins.

• Exact match. Protocol, host, and port must match. https://example.com is not the same as http://example.com, and neither matches https://www.example.com. Every subdomain you embed on must be added explicitly.
• Local development. Add http://localhost:PORT (with the port your dev server uses) to the allowlist alongside your production origins.

If the widget is embedded on a domain not on the list, the request is rejected with a 404. The widget shows a generic error; check Setup → Origins and add the missing host.

Geo restrictions

Pick Allow or Block under Setup → Anti-abuse → Geo restrictions, then list the countries with ISO 3166-1 alpha-2 codes (e.g. US, DE, JP).

• Allow. Only listed countries can sign up. Everyone else shadow-accepts.
• Block. Listed countries are blocked; everyone else passes.
• Off. The geo gate is skipped.

Challenge

A small token with two simple rules:

• Min age. The token must be at least 250ms old when redeemed. This stops bots that submit instantly.
• Single use. Each token can be redeemed exactly once within a 30-minute lifetime.

The widget handles challenge issuance and redemption automatically. Turn the toggle on and it just works.

Proof of Work

Forces the visitor’s browser to find a nonce whose hash satisfies a difficulty target. It takes a fraction of a second on a modern device but is an enormous cost when scaled across thousands of bot requests.

The widget’s SDK ships a JS solver. Turn the toggle on and the embed handles it.

Per-waitlist throttle

Defaults to 60 requests per IP per waitlist per minute. Returns an honest 429 with a Retry-After: 60 header so legitimate developers debugging a high-volume integration get a clear signal.

This is the only abuse gate that is not shadow-accept. It’s deliberately visible because hitting it is almost always a developer problem rather than abuse.

Disposable email blocklist

A static list of known throwaway providers (Mailinator, GuerrillaMail, etc.). Matches shadow-accept. If you don’t want to block disposables, turn the toggle off. There’s no granular per-domain override.

Per-email throttle

The same email can attempt at most 5 signups per hour across your account. This catches credential-stuffing-style probes that try the same email against many waitlists.

Email normalisation. Before any storage or rate-limit lookup, addresses are normalised:

• +suffix is stripped ([email protected] becomes [email protected]).
• Gmail-style dots are collapsed ([email protected] becomes [email protected]).

So [email protected], [email protected], and [email protected] are all the same address for throttling and deduplication.

MX verification

Looks up MX records for the email’s domain over DNS. If the domain has no MX records, the signup shadow-accepts. On timeout the gate fails open (so we don’t punish users for slow DNS resolvers).

Recommended settings

For most public landing pages, this combination stops the long tail of automated abuse without inconveniencing real users:

• Block disposable emails. On.
• Verify MX records. On.
• Require Challenge. On.
• Require Proof of Work. Off (turn on if you start seeing scripted abuse).
• Geo restrictions. Off (only enable for compliance reasons).

The widget handles Challenge and Proof of Work transparently. Your visitors won’t see them.