Working With OAG Flight Data When You're Under Time Pressure
OAG has been the default flight schedule database for the travel industry for decades. Airlines, OTA platforms, and corporate travel teams all pull from their data, but the actual experience of using it is nowhere near as smooth as the sales deck would have you believe. I spent roughly three years integrating OAG feeds into a booking engine before moving on, and even now I see people struggling with the same basics. The core product most people encounter is the flight schedule file. It comes in XML or CSV format, updated daily, containing departure/arrival times, airport codes, aircraft types, flight numbers, and frequency data. The files are large. A single day's schedule for global coverage runs about 400 to 600 megabytes uncompressed. If you're pulling this manually every day without automation, you're already behind. The API route is more practical for most teams. OAG offers several API endpoints covering flights, schedules, on-time performance, and routes. You'll need to sign up through their sales team first — there is no self-serve checkout. Expect a somewhat tedious onboarding process that involves agreeing to their data usage terms, which are notably restrictive. You cannot resell their raw data. You can build products on top of it, but the licensed use cases are tightly defined.
One thing most guides won't tell you: the API response structure changes more often than you'd expect. I ran into this when a schema update removed the frequency field from the schedule endpoint without any announcement in their changelog. We had a product page showing zero-flight-week routes because our parser was silently dropping that data. The fix was setting up a diff alert against the sample XML they provide, which catches structural changes before they hit production.
How to actually set this up without losing a week
Start by requesting their sample data package. Their support will send it within a day or two. Parse that first. Build your ingestion pipeline around it. Once that works, swap in your production credentials and watch the real data flow in. This order matters because the sample data includes documentation that their public API docs sometimes gloss over. The rate limits on their standard plan are generous enough for daily batch updates, but if you're doing real-time lookups during peak travel seasons, you'll want to negotiate a higher tier. Their sales team will push you toward enterprise pricing quickly. In my experience, mid-tier plans that support 100 requests per second are sufficient for most OTA-sized operations. Going beyond that rarely pays for itself unless you're handling thousands of queries per minute. The on-time performance data is where OAG actually separates itself from cheaper alternatives. The historical accuracy rates are reliable because they pull from airline-reported schedules rather than passenger complaint data. This matters when you're building delay prediction models or compensation eligibility checks. The schedule data alone gets you 80 percent of the way there. The OTP add-on closes the gap.
Get the Full Details
Pitfalls that will eat your budget
The biggest hidden cost is the data refresh cycle. OAG's schedules update once per day, usually by midnight UTC. If your product needs to show next-day flight changes made after that window, you're going to have a bad time. Airlines frequently adjust departures on the day of travel, and OAG data won't reflect those until the next daily load. Some enterprises run their own cache layer that ingests OAG nightly and then overlays live ADS-B or airline API data on top, but that's a significant engineering commitment. Another issue is code standardization. OAG uses IATA airport and airline codes, but they occasionally include legacy codes or one-off variations that break naive parsers. A flight might list an airport using a code that was retired years ago in certain systems. The workaround is maintaining a mapping table and running periodic validation sweeps. I wrote a script that compared incoming OAG data against IATA's current code registry and flagged mismatches. It ran once a week and caught about twelve anomalies per month across our global dataset. Small number, but each one could silently break a routing calculation. The pricing structure is also not transparent. They don't publish it. You negotiate per seat or per request volume, and the quotes vary wildly depending on whether you're a startup or an established airline. A small OTA might pay two to five thousand dollars monthly. A large one could easily exceed fifteen thousand. Factor that into your runway before you sign anything.
When OAG isn't the right call
If you only need basic flight schedules for a personal project or a small startup with tight margins, consider alternatives like the AviationStack API or even scraping publicly available flight data from sources like Flightradar24's free tier. These won't match OAG's completeness or reliability at scale, but they're free or nearly free, and for low-volume use cases that's acceptable. If you're building something that requires real-time accuracy across all major carriers globally, OAG is still the industry standard. The data quality justifies the cost once you're past the initial integration headaches. Most teams I know abandon the project before reaching that point because they underestimate the parsing complexity and the ongoing maintenance burden. The sample data and developer documentation live at oag.com under their API section. Their support response time averages two to four business days, which is slow compared to modern SaaS expectations but standard for this kind of legacy enterprise tool. Plan your integration timeline accordingly. Expect six to eight weeks from contract signing to a working production pipeline if your team is experienced with API integrations. Add another two to four weeks if you're learning as you go.
