Seat spinning bots follow a short, repeatable path through an airline's booking flow: search for a target flight, add seats to cart, place an order that holds the seats, let the hold expire, and repeat. Each step uses an endpoint the airline built for customers, and each request looks valid on its own. The path itself gives the campaign away, along with the infrastructure and timing behind it.
This post walks through a spin campaign the way a detection team sees it, stage by stage, and covers the related automation that usually runs alongside it. Most of these signals only mean something in combination, since any one of them individually looks legitimate.
Stage one: fare scraping and target selection
A campaign starts with reconnaissance, as seat spinning bots query search and fare endpoints continuously to find flights where holds will move the price most: routes close to a fare bucket change, departures inside a peak window, or flights a competitor wants to undercut. This fare scraping typically runs around the clock with no day-night pattern, which separates it from human shopping, where traffic rises and falls with time zones and working hours.
Many campaigns skip the website entirely. Attackers call booking APIs directly, often with session tokens harvested in bulk by separate automation, a practice known as token farming. Direct API access removes the browser from the session, so the telemetry and tracking a website would normally collect never appears.
Stage two: booking API abuse at order creation
With targets selected, the bots move to cart and order creation. A human traveler searches several times, compares options, enters passenger details, and then commits. Seat spinning bots take the fewest steps the booking flow allows, from search to cart to order, and create orders within seconds of cart creation, faster than anyone could realistically fill out the required information. The order places seats in a pending, unpaid state, and the bot moves on to the next one.
The order endpoint is doing its job, which makes this booking API abuse in its plainest form: the client calling the endpoint has no intention of paying. Request-level inspection only sees a well-formed order and lets it through.
Stage three: residential proxies and rotation
Volume would give a single client away, so attackers spread the work. Residential proxies route requests through consumer IP addresses, often thousands of them across dozens of countries, keeping each address's request count and reputation score low. Some campaigns pair that rotation with narrow user-agent diversity, presenting a handful of browser identities across a very large pool of IPs, an anomaly that shows up once a defense compares user agents with IP addresses.
Blocking residential proxies by reputation mostly blocks real customers who share those networks. The more useful question is which behavior repeats across addresses, regardless of where the traffic originates.
Stage four: expire and repeat
When the hold window closes, the seats return to inventory and the bots can hold them again. A single campaign can cycle the same seats thousands of times a day, and the cycle tightens as departure approaches and prices grow more sensitive to availability. Concentration is the clearest signal at this stage: ordinary travelers create one or two holds apiece, while a small cluster of automated sources creates the overwhelming majority.
Some attackers time the cycle to the airline's hold window, releasing seats just before expiry and re-holding them immediately, so availability never returns long enough for a traveler to book. Others spread holds across many flights on the same route, which keeps any single flight's numbers within normal ranges while the route as a whole stays scarce.
Seat spinning bots rarely work alone
The automation stack behind seat spinning supports other abuse on the same booking platform. The fare scraping from stage one also feeds competitors and resellers. Farmed tokens support fake account creation and promotion abuse. The same attackers often target loyalty programs with credential stuffing to drain miles, and they probe voucher, upgrade, and ancillary APIs for logic they can exploit. A defense built only for seat holds sees only one symptom of a broader automated operation.
Following the journey instead of the request
Cequence Bot Management correlates each stage of the booking journey, so the patterns above appear as one connected campaign instead of one request at a time. Behavioral fingerprints track the same automated entity across rotating residential proxies. Journey analysis connects search, cart, order, and payment, and flags sessions that hold seat after seat without paying. Cequence also flags impossible journeys, sequences no human traveler could complete: an order placed seconds after a cart with no time to enter passenger details, a session that skips steps a real purchase requires, or activity that moves between countries faster than anyone could travel. Search-level detection catches the scraping that precedes a campaign, before a single seat is held.
Detection runs on the network with no JavaScript or mobile SDK, so it covers direct API traffic and the website equally. The same deployment protects against fare scraping, loyalty account takeover, and fake account abuse alongside seat spinning.
The seat spinning series
This post is part three of a series on seat spinning:
