AirScalp is built around a simple idea: the traveler defines an acceptable trip before the software starts watching. A low fare is useful only if it is for the right route, dates, cabin, passengers, and total price.
The beta begins with flight monitoring. You provide your own supported flight-data API key, save a rule, and choose what AirScalp should do when a matching fare appears.
1. Define an acceptable trip
A rule starts with the details that make a flight usable. You can specify an origin and destination, acceptable nearby airports, an exact date or flexible window, passenger count, cabin, stop limit, and other itinerary constraints available in the beta.
This prevents an eye-catching price from being treated as a match when the itinerary itself does not work.
2. Set a target and a hard maximum
The target is the price you hope to find. The hard maximum is the total AirScalp is never allowed to exceed for that rule. Keeping those values separate lets you monitor aggressively without giving the booking workflow an open-ended budget.
You can also set a monitoring deadline and allowed action window. When the trip is no longer useful, the rule should expire instead of continuing indefinitely.
3. Choose what happens after a match
- Alert only: AirScalp sends the matching itinerary and you decide what to do.
- Approval required: AirScalp prepares the match but waits for your confirmation.
- Automatic booking: AirScalp may attempt a purchase only after you explicitly enable the rule and add an approved payment method.
You can begin with alerts and move to a more automated mode after you understand how your rules behave.
4. Recheck before action
Airfares move quickly. A match must be revalidated before any booking attempt. AirScalp checks that the itinerary is still available, the total remains inside the hard limit, and the saved rule still permits action. If a required condition fails, the correct result is to stop.
No flight price tracker can guarantee inventory or a fare until the airline or booking provider confirms the transaction.
5. Review what happened
The planned audit trail records monitoring checks, candidate fares, rejected matches, notifications, approvals, and booking attempts. That history is important when automation does nothing: it should show whether the fare was too high, the itinerary broke a rule, the rule expired, or inventory changed.
Review the booking controls and purchase logic before joining the beta.