Slide 5 of 28
Part 1 · What Is It?Slide 5
Slide 5 · Why It Keeps Happening
APIs are built for users. Bots aren’t users.
Three design assumptions that automation breaks.
Assumption 1: “Users complete flows at human speed”

Business logic is designed for a person: browsing, selecting, entering payment, waiting for confirmation. The flow takes 2–5 minutes for a human. A bot completes it in milliseconds. No inventory reservation system, no purchase limit, no fraud detection was calibrated for millisecond completion. The business logic had no concept of “this is too fast.”

Assumption 2: “One person, one session”

The checkout flow assumes one person is checking out. Bots run hundreds or thousands of parallel sessions — each holding tickets in a cart, each completing the checkout independently. The per-session limit is fine; the absence of a per-account or per-identity limit is the gap.

Assumption 3: “Security controls stop abusers”

Authentication, rate limiting, and fraud detection focus on unauthorized access. Business flow abuse is authorized — the bot has a valid account and a valid payment method. Traditional security controls don’t catch it because the requests are technically legitimate. The problem is the intent and the scale, not the authorization.

Why this is hard

There is no technical signature that distinguishes a bot completing a checkout from a very fast human. The defense requires business-level rules (max 2 tickets per account), behavioral analysis (completed checkout in 200ms), and human verification challenges — none of which are standard API security controls.

← Back What’s the actual damage? →