July 17, 2026 · Qasim Jaffery

API standard before APIs existed.

Diagram explaining EDIFACT messaging architecture used by airlines, travel agencies, Sabre, Amadeus, Galileo, and GDS systems to exchange standardized reservation, ticketing, and travel data before modern REST APIs and JSON.

What is EDIFACT?

EDIFACT stands for:

Electronic Data Interchange for Administration, Commerce and Transport

It is an international electronic messaging standard developed by the United Nations (UN/CEFACT) in the late 1980s.

Its goal was simple:

Enable computers from different companies to exchange business documents automatically without human intervention.

Instead of sending paper documents or proprietary data formats, businesses exchanged standardized electronic messages.


Think of EDIFACT Like This

Today we exchange JSON.

{
  "flight":"AI101",
  "date":"2026-07-15",
  "passenger":"John Smith"
}

Back then the same information looked something like this:

UNH+1+PAORES:93:1:IA'
MSG+1'
IFT+3'
ERC+A7V'
TVL+240715:0900::AI:101:Y'
PDI++John:Smith'
UNT+25+1'

Not very human-friendly, but computers understood it perfectly.


Why Was EDIFACT Needed?

Imagine the airline industry in the 1980s.

You had:

  • Airlines
  • Travel Agencies
  • Airports
  • Hotels
  • Car Rental Companies
  • Cargo Companies
  • Customs
  • Immigration

Everyone needed to exchange information.

Without a standard:

Airline A
↓

Custom Format
↓

Travel Agency
Airline B
↓

Different Format
↓

Travel Agency
Hotel

↓

Another Format

Thousands of integrations.

Sound familiar?

Exactly the same problem Open Responses is solving today.


The Solution

EDIFACT defined standard message types.

Everyone agreed on the format.

Travel Agency

        │

     EDIFACT

 ┌──────┼────────┐

 ▼      ▼        ▼

Sabre  Airline  Hotel

Everyone spoke the same language.


Anatomy of an EDIFACT Message

An EDIFACT message is made of segments.

Each segment begins with a three-letter identifier.

Example:

UNH

Message Header

MSG

Message Type

TVL

Travel Details

PDI

Passenger Information

UNT

Message End

Think of them like JSON properties.

JSON

{
   "flight":"AI101",
   "passenger":"John"
}

EDIFACT

TVL+AI101'

PDI+JOHN'

Different syntax.

Same idea.


Example Airline Booking

Imagine booking a flight.

The information includes:

  • Passenger Name
  • Flight
  • Date
  • Seat
  • Ticket

Today

{
  "passenger":"John Smith",
  "flight":"AI101",
  "seat":"12A"
}

EDIFACT

PDI+JOHN:SMITH'

TVL+AI101'

SEA+12A'

Common Travel EDIFACT Messages

The travel industry standardized many message types.

PNR Creation

Passenger Name Record

Creates a reservation.


AIR Availability

Searches flights.

Availability Request

↓

Availability Response

Booking

Books seats.

Booking Request

↓

Booking Confirmation

Ticketing

Issues tickets.

Ticket Request

↓

Ticket Confirmation

Cancellation

Cancels bookings.


Schedule Changes

Airline sends schedule updates.


Fare Quote

Calculates ticket prices.


Baggage Information

Transfers baggage details.


Passenger Status

Updates check-in and boarding information.


Inside Sabre

When you typed

1AI

or

01Y15JULDELBOM

Sabre wasn’t sending those cryptic commands directly to the airline.

Internally it translated them into structured messages—historically using EDIFACT-based and related industry messaging formats—sent them to the airline host, and then translated the response back into the familiar green-screen display.

So the flow was roughly:

Travel Agent

↓

Sabre Command

↓

Sabre Internal Translation

↓

EDIFACT-style Message

↓

Airline Reservation System

↓

Response

↓

Sabre Screen

The travel agent never saw the EDIFACT message.


Why Was It Revolutionary?

Before EDIFACT

Every airline

↓

Different protocol

After EDIFACT

Every airline

↓

Same protocol

Integration costs dropped dramatically.


EDIFACT vs Modern JSON

EDIFACTJSON
Text segmentsKey-value pairs
Very compactHuman-readable
Fixed standardsFlexible schemas
Excellent for EDIExcellent for web APIs
Difficult to readEasy to understand
Built for business messagingBuilt for web services

The Evolution of Travel Standards

1980s

EDIFACT
      │
      ▼

AIRIMP
      │
      ▼

OTA XML
      │
      ▼

SOAP APIs
      │
      ▼

REST APIs
      │
      ▼

JSON APIs
      │
      ▼

NDC JSON/XML

Each step made integrations more developer-friendly while preserving the underlying business concepts.


The AI Parallel

This is where history repeats itself.

Travel Industry (1980s)

  • Problem: Every airline had a different messaging format.
  • Solution: EDIFACT standardized business communication.

Web Industry (1990s)

  • Problem: Every website communicated differently.
  • Solution: HTTP standardized web communication.

Database Industry

  • Problem: Every database had its own query language.
  • Solution: SQL became the common standard.

AI Industry (Today)

  • Problem: Every AI provider has its own API and message format.
  • Proposed solution: Open Responses aims to define a common request and response standard so applications can communicate with multiple AI models through a consistent interface.