How much latency does this add to results?

One GET per route, ~50ms from cache, no request body. It drops into the results render path without meaningful latency — most integrations fetch in parallel with fare data and render the badge when it lands.

The sandbox is free on live data, no card — embed the badge in your staging build today. Production runs on request volume: Starter $2,000/month, Pro $5,000/month with SLA and webhooks. Full grid on the pricing page .

Do we send you any customer data?

No. The request is two airport codes (optionally via and date) — no passenger data, no identifiers, no cookies. GDPR-neutral by design; most teams clear it without a privacy review.

What exactly do we show the traveller?

That’s your call — the API returns score (0–100) and risk_level (low / moderate / high / critical); you control presentation. The signal is information about the airspace a route crosses, not travel advice — pair it with a link to what the number means.

What about routes you don’t cover?

The response says so explicitly: coverage.status = "out_of_scope" with score: null . Show nothing, or "not monitored" — and your booking agent branches cleanly instead of stalling. 334 FIRs are scored daily; never treat null as zero risk.

Will the badge flap and scare users off?

Scores recompute every 5–30 minutes, but the four risk levels are banded — level changes are far rarer than score moves. Badge on risk_level and the UI stays stable while staying current.

For travel platforms & OTAs

The trust signal
your search results are missing.

A single GET returns a 0–100 airspace-risk score for any route in ~50ms — no PII, no privacy review. Badge it on results, warn at checkout, or gate your booking agent. Your users see which routes fly through risk before they pay — and the refund cascade never starts.

Get a free sandbox key → Open the badge generator ↗

Sandbox free · production from $2K/mo — no card, no sales call. Full grid on the pricing page.

Proof it's live · badge on a mock result

Pick a route — the badge renders from the live engine, exactly as it would on your results page.

LHR → DXB

07:35 – 18:20 · 1 stop · 6h 45m

airspace … $562 Select

Live score, mock fare. Copy a production-ready snippet in the badge generator. Information about the airspace a route crosses — not travel advice.

The problem lands at the end of your funnel.

Customers book through risk blind

Search results surface routes that won’t actually fly. The booking confirms; 24 hours later the airline reroutes through a 6-hour-longer path — or cancels. You eat the refund and the complaint.

Cancellation cascades kill conversion

A live closure turns confidently-sold fares into rebookings exactly at the end of the funnel, where it hurts most.

No way to differentiate

No major aggregator surfaces airspace risk today. You compete on price and inventory — there’s no trust signal that sets you apart.

Agentic booking stalls on exceptions

AI booking agents need a clean, machine-readable gate before committing a fare. Narrative risk doesn’t scale; a 0–100 field does.

Closure week

Fares sold Tuesday. Reroutes announced Thursday — six hours longer, or cancelled outright. The complaint that lands in your queue reads: "you sold me this flight."

The platform that showed a risk badge at search time had that conversation before the payment — as information, on the user's terms.

How it drops in.

Call one endpoint.

Closes: booking through risk blind. GET /v2/route/risk?from=…&to=… — no body, no PII, ~50ms from cache. Drops into your results render path without meaningful latency.

Read two fields.

Closes: agents stalling on exceptions. score (0–100) and risk_level (low / moderate / high / critical). Colour a badge, trigger a checkout notice, or gate an AI booking agent on a single numeric field.

Refresh handled for you.

Closes: the cancellation cascade surprising you. Scores recompute every 5–30 minutes across 334 daily-scored FIRs; scored_at drives your cache. You always render current risk, never a stale snapshot.

The response, field by field.

Everything your badge, checkout notice, and booking agent need — the sellable unit is this JSON.

GET /route/risk?from=LHR&to=DXB

~50ms · JSON

{
  "from": "LHR", "to": "DXB",
  "date": "2026-07-14",
  "score": 33, "risk_level": "moderate",
  "confidence": 0.85,
  "coverage": { "status": "covered", … },
  "scored_at": 1783641600
}

score · risk_level

The whole integration reads two fields — badge colour from risk_level, sorting or gating from score. No parsing, no prose.

coverage

Out-of-coverage is explicit — status: "out_of_scope", score null. Your agent branches cleanly; your UI shows nothing rather than a guess.

scored_at

Unix timestamp for cache invalidation — render current risk at ~50ms without hammering the API on every impression.

Illustrative values — the field shape is the exact v2 contract. Scores refresh every 5–30 minutes; always branch on coverage.status, never treat null as 0. Full contract: API docs.

Why you can put it in front of users.

What's behind the badge

→ 334 FIRs scored daily from public regulatory & operational data — EASA · FAA · ICAO · ADS-B · conflict-event signals
→ Documented methodology you can link from your own help pages
→ No PII in any request — two airport codes in, one number out

What we do NOT claim

× Travel advice. The badge is information about the airspace a route crosses — the traveller decides; your UI should say so too.
× Flight-safety prediction. It indexes airspace conditions, not the safety of a specific flight or carrier.
× 100% accuracy. Scores are validated against an event ground truth; every score carries confidence and coverage.

How to start.

API pricing — per request volume

Sandbox free · Starter $2K/mo · Pro $5K/mo (SLA + webhooks)

Badge and checkout-warning integrations run on API request tiers; free sandbox for your staging build.

See API plans → Get sandbox key

For the care & disruption team

The same engine runs as a signed-in workspace — check a disrupted route, keep a dated record of what was known when. Console from $99/month, 14-day free trial, no card.

See Console plans →

Try the API — free sandbox, no card

Get a sandbox key and embed the route-risk badge in your staging build in minutes. Single GET, ~50ms, no PII. Production keys, higher rate limits, and webhooks come with a plan.

Get dev sandbox key →

Built for platforms like

Booking.comSkyscannerKayakWegoExpediaTrip.comMakeMyTripCleartrip

Airspace risk in the shopping flow — FAQ

Common search queries answered with current status, FIR codes, and source citations.

How much latency does this add to results?: One GET per route, ~50ms from cache, no request body. It drops into the results render path without meaningful latency — most integrations fetch in parallel with fare data and render the badge when it lands.
What does it cost?: The sandbox is free on live data, no card — embed the badge in your staging build today. Production runs on request volume: Starter $2,000/month, Pro $5,000/month with SLA and webhooks. Full grid on the pricing page.
Do we send you any customer data?: No. The request is two airport codes (optionally via and date) — no passenger data, no identifiers, no cookies. GDPR-neutral by design; most teams clear it without a privacy review.
What exactly do we show the traveller?: That’s your call — the API returns score (0–100) and risk_level (low / moderate / high / critical); you control presentation. The signal is information about the airspace a route crosses, not travel advice — pair it with a link to what the number means.
What about routes you don’t cover?: The response says so explicitly: coverage.status = "out_of_scope" with score: null. Show nothing, or "not monitored" — and your booking agent branches cleanly instead of stalling. 334 FIRs are scored daily; never treat null as zero risk.
Will the badge flap and scare users off?: Scores recompute every 5–30 minutes, but the four risk levels are banded — level changes are far rarer than score moves. Badge on risk_level and the UI stays stable while staying current.

FlySafe provides automated computation of numerical indices from publicly available data. Indices are raw computational output and do not represent opinions, assessments, recommendations, or advice of any kind. They are not travel advice and do not predict the safety of any specific flight. See Terms of Service.