Context
A sneaker raffle gives customers time to enter a release without racing through checkout. That is useful for a high-demand drop. It also changes the problem your team needs to solve: an operator who controls hundreds of entries can gain an advantage long before winners are selected.
The entry form, account rules, draw, and purchase invitation all affect the outcome. Each needs clear limits and a way to recognize coordinated activity. For brands and retailers, raffle protection starts with defining what a valid entry means and making that rule hold across the release.
Table of contents
What is a sneaker raffle?
A sneaker raffle allocates the opportunity to buy a limited release through a draw from eligible entries. Depending on the retailer's rules, a selected customer may receive a purchase invitation or complete a previously authorized purchase.
A draw reduces the advantage of submitting the fastest checkout. The quality of the entry pool still matters. If one participant can register many accounts and enter each account separately, the draw can faithfully select from a pool that already contains unfair repetition.
Keep the entry rules visible: who can enter, how many entries are permitted, when registration closes, how selection works, and how winners complete their purchase. Customers should understand the process before they hand over their details.
Where bots gain an advantage
Raffle abuse often starts with account preparation. An operator can create accounts, verify contact details, and submit repeated entries through different browser profiles or networks. OWASP identifies account creation for subsequent misuse as a distinct automated threat.
Look beyond entry speed. Relevant patterns include a group of accounts completing the same sequence, repeated devices appearing across identities, and coordinated activity targeting the same sizes or products. Delivery details and purchase outcomes can add context when your process collects them.
A single overlap is a starting point for investigation. Two siblings may share an address and a laptop. Fans may enter together as soon as registration opens. Restricting every shared network would create avoidable exclusions.
Define the entry rule before choosing a control
“One entry per account” and “one entry per customer” require different checks. The first limits a database identity. The second requires a way to investigate whether several accounts represent the same participant.
Agree on the rule with commerce, engineering, fraud, and customer support before registration opens. Document whether customers can change their size selection, how corrections are handled, and what happens to an entry that needs review.
Avoid changing eligibility during the draw without a clear process. A support agent should be able to explain why an entry was accepted, corrected, or removed. Retain the policy version and relevant evidence so the decision can be reviewed afterwards.
Protect registration and entry submission
Enforce eligibility on the server for every entry path, including mobile routes and direct API requests. Require the necessary verification state before accepting an entry. Closing a button in the interface should not leave the submission endpoint open.
Make repeat submissions predictable. If a customer retries after a connection error, the system should return or update their existing entry according to your rules. It should not silently create another chance in the draw.
Test the final entry limit under concurrent requests. Two requests arriving together must not both pass a check that permits only one entry. This is a practical application of OWASP's guidance on limiting repeated business functions.
Apply limits where activity becomes costly: account registration, verification attempts, and raffle submission. Set them from observed traffic and the release's rules. Registration for a popular collaboration can be much busier than an ordinary product launch.
Review relationships before the draw
Set aside time to review suspicious entry groups before selection. A useful investigation connects accounts, sessions, device signals, entry timing, and the release they targeted.
For example, several accounts sharing a device may be understandable. The same accounts entering in a repeated mechanical sequence, switching identities rapidly, and reproducing the pattern across releases deserve closer review. Several independent signals make the decision easier to defend.
Separate detection from the raffle's allocation rules. Your protection layer can identify likely abuse; your raffle system still needs to apply eligibility and selection consistently. Record the eligible pool used for the draw and how reviewed entries were handled.
Kairal's sneaker protection uses device correlation and cross-session analysis to help teams investigate accounts involved in coordinated activity. Its COMPOSITE® technology adds context across visits and accounts. These signals support an investigation; your release rules determine the resulting action.
Carry eligibility into the purchase invitation
Protect the route from selection to purchase. Where your raffle promises access to a selected customer, bind the invitation to that account, give it a clear expiry, and validate the permitted product and quantity on the server.
Check that a used invitation cannot create additional orders and that an expired invitation cannot reserve inventory indefinitely. Decide what happens after a payment failure: the customer may need a reasonable retry window, while inventory still needs a defined release path.
Customer support should be able to distinguish an expired invitation from a blocked purchase or a payment decline. Those are different problems and call for different responses.
Measure the release beyond entry count
More entries do not automatically mean more independent demand. Review valid entries, duplicate submissions, groups removed after investigation, and the rate at which selected customers complete purchases.
Track customer impact alongside enforcement. Look at verification abandonment, entry failures, review turnaround, and support complaints. If a rule excludes customers sharing household devices, investigate that effect before using it on the next release.
Compare similar releases and size allocations where possible. Product popularity and stock availability affect the outcome, so a change in conversion should not automatically be credited to bot protection.
Before your next draw, test registration retries, concurrent submissions, shared-device households, purchase-invitation reuse, and failed-payment recovery. Give the live team an owner for each decision and a route for reviewing exceptions.
To assess coordinated activity around your release, discuss your entry and purchase journey with Kairal. Bring the actual eligibility rule and the points where customers or operators can repeat an action.