Seat spinning mitigation works best as a sequence: monitor booking traffic, validate findings against real reservations, block at order creation, then extend enforcement upstream to search. Two airline engagements show each phase of that sequence, from the first day of detection to the attackers' escalations once blocking began.
Seat spinning detection from one day of traffic
A leading international airline suspected bots were holding seats through its booking APIs without paying, and it provided Cequence with a day’s worth of production traffic to investigate. On a revenue-sensitive booking platform, a false positive means a traveler can't buy a ticket, so the carrier wanted proof before any enforcement. Running in monitoring mode, with no application changes and no tuning cycle, Cequence Bot Management scored every request and identified roughly half of that day's seat holds as likely seat spinning.
One day was enough because spinners repeat the same cycle many times a day, and Cequence's behavioral models start with an understanding of normal booking behavior instead of learning it from a baseline period.
What traffic monitoring revealed
About two dozen automated sources accounted for roughly 98% of the holds Cequence flagged, while everyone else created a handful of holds apiece, consistent with ordinary travelers each booking a single trip. The bots hid behind clean residential proxies rotating across thousands of IPs and dozens of countries, keeping each address's risk score low enough to pass the airline's existing reputation checks.
Behavioral signals separated the cluster from real customers: sessions went straight from search to cart to order with no other steps, orders arrived seconds after cart creation, and repeat bookings accumulated within single sessions that carried almost no browser telemetry. These signals only appear when a defense analyzes a sequence of requests, or behavior, together. Cequence's behavioral intent engine found them by correlating each entity's steps across sessions and IP addresses, and behavioral fingerprints followed the same client as it rotated through proxies.
Detection accuracy checked against real reservations
Cequence validated its findings against the carrier's reservation records, comparing flagged holds with the bookings that went on to payment, and confirmed a false positive rate of 0.4%. That miniscule figure let security and revenue management agree on what enforcement would cost before anyone switched it on, which is the point of seat spinning detection that starts in monitoring mode.
Order creation is the low risk first move
Creating an order is what places a seat on hold, so seat spinning mitigation usually starts there: blocking stops the harm directly, and monitoring data shows whether each order the policies would have blocked was ever paid for. The first airline's model showed that blocking at order creation would have stopped close to 30% of the day's order attempts, and roughly 87% of the holds those policies would have blocked went unpaid, far above the airline's baseline.
Bots retool once blocking starts
In the second engagement, another airline saw seats repeatedly held and released on key regional routes, and the business typically noticed the abuse only the following day. A two-week monitoring phase surfaced continuous fare and inventory scraping with no day-night pattern, token farming, and direct API calls that bypassed the airline's website, all before the bots started spinning seats.
When blocking went live at order creation, Cequence built a rule that caught the remaining seat spinning activity within about two hours. Cequence machine learning models train on hundreds of request attributes to automatically generate bespoke blocking policies, work that would normally take analysts hours or days of log review during an active attack. The next day, the bots retooled and spinning resumed, the usual reaction once mitigation starts costing an operator money.
Blocking abusive search stops seat spinning at its first step
Spin campaigns typically use search to find which flights and fares to target, so search blocking cuts off the data those campaigns depend on, which makes it the strongest seat spinning mitigation step once order-level data shows the policies are safe. The second airline's leadership approved blocking abusive search traffic, and Cequence switched it on live during the escalation call. The carrier reported no further suspected seat spinning for the rest of the two week engagement.
At the first airline, extending enforcement to search blocked about one million abusive searches a day and cut attempted seat spinning orders by more than 90% overall. For one full day, the airline saw effectively no seat spinning orders at all. Revenue was unaffected and conversion rates rose. Search blocking also lowers infrastructure costs, since every automated search consumes compute and fare calculation, and in many airline architectures it triggers a paid availability request to a distribution system.
Metrics security and revenue teams can share
These Cequence engagements started in monitoring mode on booking APIs, with daily seat spinning KPI reports that give security and revenue management the same view of the abuse:
- Unpaid holds as a share of all holds, by route and time of day
- Unpaid holds that remain after subtracting likely human behavior
- Probable seat spinning events, and the share detected, flagged, and blocked
- Hold-to-payment conversion and overall booking funnel conversion
- Searches per completed booking, before and after enforcement
Some unpaid holds come from real travelers who change their minds, so the reports remove holds that match normal traveler behavior before counting the rest as likely abuse. Counting every unpaid hold as abuse overstates the problem and costs the security team credibility with revenue management.
Seat spinning mitigation that adapts
Cequence Bot Management deploys without JavaScript, mobile SDKs, or application changes, and it can run behind an incumbent bot solution, so a carrier sees what its current defense misses before changing anything. When bots retool, Cequence automatically generates new policies from the new attack sample instead of waiting on hand-written rules. Behavioral intent analysis of this kind is how Cequence approaches business logic abuse generally, and because the Cequence Platform shares detection between bot management and API security, the booking APIs bots call directly receive the same protection as the website, along with the fare and inventory data scrapers would otherwise collect.
The seat spinning series
This post is part four of a series on seat spinning:
