Corporate Travel Risk Management — Duty of Care Data for TMC Platforms

Corporate travel risk management explained. How TMC platforms and enterprise travel systems build duty of care compliance using real-time flight tracking, webhook alerts and geographic data. Business traveler tracking, disruption detection and crisis response via the AirLabs API.

Sergey St.

Published on Jul 21st 26

Share:

• 
• 
• 

What Duty of Care Actually Requires

Corporate travel risk management is not primarily about convenience or customer service. It is a compliance discipline anchored in employer legal obligations that exist independently of whether the traveller is aware of them. When an employee travels on company business, the employer becomes responsible for that employee's safety, situational awareness and access to support during disruption. In most legal systems, that responsibility is called duty of care, and it has direct operational implications for the systems that manage business travel.

The ISO 31030 standard, published in 2021, made these obligations explicit for the first time as an international framework. It requires that organisations identify risks associated with travel, monitor travellers throughout their journeys, communicate promptly during incidents, and demonstrate afterwards that reasonable care was exercised. The last requirement is subtle but important — duty of care is not just about doing the right thing; it is about being able to prove after an incident that the right systems and information were in place.

For Travel Management Companies (TMCs), corporate booking platforms and enterprise travel systems, this means the traveller-tracking layer is a required part of the stack — not an optional feature. This guide explains what data feeds are needed for that layer, how they integrate with existing corporate travel infrastructure, and how the AirLabs API supplies the flight data component of a compliant duty of care implementation. It is a technical companion to the corporate travel section of our Real-Time Flight Tracking for Business guide, which introduces the topic at a general use-case level.

"Duty of care is not proven in a single moment of crisis. It is proven in the accumulated record of data captured, decisions made and communications sent before, during and after every trip. The data feeds behind that record are the actual compliance artefact — the technology stack is the risk management strategy in operational form."

The Flight Data Layer in a TMC Architecture

A modern corporate travel platform combines several data domains. The employee identity and booking records live in the TMC's own database. Policy rules, expense management and approvals sit in the enterprise's travel management platform. Ground services — hotels, ground transport, corporate cards — come from their respective providers. The flight data component — where any employee's flight actually is right now, whether their booking is at risk, what alternatives exist — comes from a flight data API.

This architectural separation matters. The TMC owns the booking-to-employee mapping — the fact that "employee Sarah Chen is on BA117 tonight." The flight data API owns the live operational state of that flight number — its current position, delay, gate, terminal and status. Neither can produce duty of care compliance alone. The compliance value is created by joining the two: the TMC's booking record with the live operational state from the AirLabs API.

For every scheduled traveller, the TMC platform holds the flight identifier (flight_iata) plus the employee record. The AirLabs API is queried against that identifier to retrieve the live state. Combined, they answer the questions that duty of care demands: where is each traveller, when will they arrive, has anything changed, what should be done next.

Real-Time Traveller Location via Flight Identifier

The core operational lookup is the Flight Information API, queried by flight number for each active booking:

GET https://airlabs.co/api/v9/flight?flight_iata=BA117&api_key={KEY}

{
  "flight_iata": "BA117",
  "flight_icao": "BAW117",
  "dep_iata": "LHR",
  "arr_iata": "JFK",
  "dep_time": "2026-07-21 10:00",
  "dep_estimated": "2026-07-21 10:47",
  "dep_terminal": "5",
  "dep_gate": "A22",
  "arr_time": "2026-07-21 13:15",
  "arr_estimated": "2026-07-21 14:02",
  "arr_terminal": "7",
  "status": "active",
  "delayed": 47,
  "lat": 51.28,
  "lng": -12.45,
  "alt": 10972
}

For every traveller booked on this flight, the response provides everything a duty of care system needs at that moment: the current status, the estimated arrival, the delay in minutes, and — while the aircraft is airborne — the actual latitude and longitude. The lat and lng fields answer the "where is our traveller right now" question that ISO 31030 requires when incidents happen along a route.

For a moving map view of all active travellers, the Real-Time Flights API returns positions across many flights in a single request, filterable by geographic bounding box or by specific flight identifiers.

Webhook-Driven Disruption Detection

Polling the Flight Info API for every booking every minute is technically possible but operationally wasteful. Most travellers' flights operate uneventfully; the polls return unchanged data. Duty of care compliance actually requires the opposite pattern — notification when something changes, so the travel operations team can respond before the traveller does.

This is what the Flight Alert API is designed for. A TMC platform registers webhook subscriptions for each booking's flight number. The API monitors those flights and pushes notifications when specific fields change — status transitions, delay increments, gate changes, terminal changes, estimated time shifts.

The architectural pattern in a TMC integration is:

• When a booking is created, the TMC registers a webhook subscription for the flight identifier
• As the flight progresses, the AirLabs platform detects changes and posts notifications to the TMC endpoint
• The TMC joins the flight identifier back to the employee record
• Notifications are routed to the appropriate stakeholders — the traveller, the travel operations desk, the employee's manager, the corporate security officer, depending on the type and severity of the change
• Every notification is logged with its timestamp, forming the audit trail

The audit trail is often overlooked but is the critical compliance artefact. In the event of a serious incident, the enterprise must be able to demonstrate that it received notification, that appropriate personnel were alerted, and that response actions were initiated. The webhook log is that demonstration.

Crisis Response — When Standard Operations Break Down

Duty of care standards demand more than tracking individual travellers. They require the ability to respond at scale when a large event disrupts many travellers simultaneously — an airport closure, a regional weather event, a security incident affecting an entire route or country.

For these scenarios, the AirLabs API provides two capabilities that TMC platforms integrate for crisis response.

The Flight Delay API queried by airport returns every disrupted flight at that airport in a single call:

GET https://airlabs.co/api/v9/delays?dep_iata=JFK&type=departures&api_key={KEY}

The travel operations desk can immediately identify which of their booked travellers are affected by a disruption at JFK, rather than checking each booking individually.

The NearBy API accepts coordinates and a radius and returns alternative airports for rebooking during airport closures or regional disruptions:

GET https://airlabs.co/api/v9/nearby?lat=40.6413&lng=-73.7781&distance=200&api_key={KEY}

For a JFK closure, this identifies EWR, LGA, PHL and other regional airports as potential rebooking options within a 200-kilometre radius. The response includes each airport's IATA and ICAO codes for onward booking system queries.

Combined, these two endpoints allow a duty of care team to move from "there is a major disruption at JFK" to "here are our 47 affected travellers and here are the alternative airports we can reroute them through" in seconds rather than hours.

Historical Audit Trail for Compliance Reporting

Beyond real-time response, corporate travel risk management systems must maintain records suitable for compliance audits, insurance claims and post-incident reviews. The webhook notifications from the Flight Alert API, stored as they arrive, form an operational history for every tracked flight — when a delay was first announced, when the estimated time shifted, when the gate changed, when the status transitioned from scheduled to active to landed.

For the enterprise, this history is the compliance artefact that ISO 31030's post-incident review provisions require. For the TMC, it is the operational data that supports service-level reporting to corporate clients — "here is what we knew, when we knew it, and what we did with the information." The Alert-driven history is fundamentally richer than periodic polling snapshots because it captures the sequence of changes, not just the final state.

Integrating Flight Data with Traveller Records

The TMC platform's own data — employee identity, booking, itinerary, expense — is the primary data set for a corporate travel product. AirLabs contributes the operational flight layer on top of that primary data. The integration boundary is clean: for every booking that includes a flight, the TMC queries the AirLabs API by flight identifier and joins the returned operational data back to the employee record in the TMC's own database.

A working duty of care implementation typically involves the following integration points:

• On booking creation: register a webhook subscription with the Flight Alert API for the flight identifier
• On flight departure day: query the Flight Information API to establish baseline status; if disrupted, prompt the travel desk
• During the flight: consume webhook notifications from the Alert API; join to employee records; route to appropriate stakeholders
• During disruption events: query the Flight Delay API by affected airport; identify all affected travellers; query the NearBy API for alternative airports if needed
• On flight completion: mark the booking as successfully completed; retain the notification log for the required audit period

The AirLabs component provides only the flight data. The TMC platform owns and controls all traveller data, communications routing, policy enforcement and audit-log storage.

Use Cases for Corporate Travel Risk Management Data

Different roles inside an enterprise consume different aspects of the duty of care data stack:

Corporate Travel Operations Managers

Travel desks running day-to-day operations use webhook alerts to intervene proactively when flights are disrupted. Instead of waiting for travellers to call, the desk contacts them first — often before the traveller is even aware of the delay — with rebooking options already identified.

Enterprise HR and Global Mobility

HR and mobility teams responsible for international assignments and business travel programmes use the compliance record to demonstrate duty of care to executive leadership, board audit committees and, in regulated industries, external inspectors.

Corporate Security and Risk Officers

Security functions inside multinational enterprises use real-time traveller tracking to inform decisions during security incidents — evacuations, safe location coordination, crisis communications. During major incidents, the ability to know which employees are in the air, where they are heading and when they will arrive is a critical input to executive decision-making.

TMC Product Managers Building Corporate Travel Apps

Product teams inside TMCs build the duty of care feature set as a differentiator in enterprise sales cycles. Enterprise buyers increasingly require documented traveller-tracking capability as part of the TMC selection process; the flight data feed is the technical enabler.

Legal and Compliance Teams

Legal and compliance functions define what "reasonable care" means for the enterprise and set audit requirements for the tracking system. The Alert API notification log is the artefact that satisfies those requirements.

Corporate Travel Insurance Underwriters

Travel and disruption insurance products serving corporate accounts depend on the accuracy of flight data for claims validation and pricing. The delayed, dep_delayed and arr_delayed fields from the Flight Information API are the same data points that underpin enterprise-level insurance claims workflows.

Practical Patterns for Duty of Care Implementations

• Prefer Alert webhooks over polling. The Alert API pattern captures a sequence of state changes, which is what compliance audits require. Polling produces a series of snapshots that lose the change history.
• Store notifications with server-side timestamps. For audit purposes, record when your system received the notification, not just when the change occurred. Both are useful; only the arrival timestamp proves that your system knew.
• Route notifications by severity. A one-minute delay does not require executive escalation. A cancelled flight, a diverted flight or a "no-position" gap during a security event does. Notification routing rules are essential to avoid alert fatigue.
• Join to the employee record in your own database. The AirLabs API does not know which flights carry which employees; that mapping stays in your TMC or HR system.
• Use the Airports Database for timezone conversion. Notifications and reports may be consumed across multiple timezones. Store times in UTC internally and convert for display using the timezone field from the AirLabs Airports Database.
• Combine the NearBy API with your booking engine. During disruption, identifying alternative airports is only useful if it feeds directly into rebooking. Pre-integrate the two so the response time in crisis is measured in minutes, not hours.
• Test the crisis workflow, not just the daily operations. The daily notification flow is easy to observe. The mass disruption workflow — hundreds of affected travellers, simultaneous rebooking, executive alerts — must be exercised periodically to be reliable when it matters.

Corporate Travel Risk Management for Enterprise Buyers

If you are building a TMC platform, a corporate travel app, an enterprise mobility system or any product where duty of care compliance is part of the value proposition, the AirLabs API provides the flight data layer needed to make traveller tracking reliable and auditable.

Supported API Features

Our Developer API allows you to create a custom experience for your users and increase the value of your product:

• Flight Alert API for webhook subscriptions per flight identifier and event-driven notifications on status, gate, terminal, delay and estimated time changes.
• Flight Information API for detailed status, position and delay lookup per booking's flight number.
• Real-Time Flights API for aggregate views across multiple bookings or geographic regions.
• Flight Delay API for identifying all disrupted flights at a specific airport during a disruption event.
• NearBy API for alternative airport identification during rebooking scenarios.
• Airports Database with IATA/ICAO codes, timezones and geolocation for compliance reporting.
• Airlines Database for carrier context and operational scope.
• Field selection via _fields for lean, targeted responses in high-frequency queries.
• JSON, XML and CSV response formats behind a single API key.

You can try it right now without any obligation! Get a free flight API plan and see for yourself that we have exactly the data you need!

If you need more information, don't hesitate to contact us. We are always happy to chat with our customers and are sure to find a customized solution for each request.