Two different things
An SSR (Special Service Request) is a structured message the airline system must answer. An OSI (Other Service Information) is a one-way note for information only — nobody confirms it and nobody is obliged to act on it.
Putting a wheelchair request in an OSI is one of the most common and most damaging mistakes in a travel agency, because the passenger arrives believing the service is arranged.
Standard SSR codes you use daily
• WCHR, WCHS, WCHC — wheelchair, by level of assistance needed.
• VGML, AVML, CHML, DBML and other meal codes.
• INFT and CHLD — infant and child.
• FQTV — frequent flyer number.
• DOCS, DOCA, DOCO — passport and regulatory documents (APIS).
• SEAT, BSCT, UMNR, PETC, AVIH.
Status codes decide the truth
The status the airline returns is what matters, not the fact that you sent the message.
• HK — confirmed and holding.
• KK — the airline confirmed your request.
• HN, PN — requested, still pending.
• UN, NO, UC — not accepted; the service is not arranged.
Read the element again after end of transaction and after any schedule change: a status can move from HN to UN without anybody telling you.
Practical discipline
• Send an SSR per passenger and per segment when the service is segment-specific.
• Keep free text short and in the format the carrier publishes.
• Never promise a special meal or a wheelchair to the customer while the status is still pending.
• Re-check APIS elements after a passenger name correction.
• Add a contact element so the airline can reach the passenger during disruption.
Key takeaways
• SSR asks; OSI only informs.
• The service exists only when the status says it exists.
• Codes and formats are published by the airline and by IATA PADIS/PSC standards — follow them, do not improvise.