API standard before APIs existed.

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
| EDIFACT | JSON |
|---|---|
| Text segments | Key-value pairs |
| Very compact | Human-readable |
| Fixed standards | Flexible schemas |
| Excellent for EDI | Excellent for web APIs |
| Difficult to read | Easy to understand |
| Built for business messaging | Built 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.