MAWB · HAWB
MAWB vs HAWB: one schema for air waybill extraction
Master and house air waybills look different on paper, but integrators usually want one JSON contract. DocAPI uses a single POST /v1/extract/awb endpoint for both—MAWB to JSON and HAWB to JSON without splitting your pipeline.
Quick difference
| MAWB (Master) | HAWB (House) | |
|---|---|---|
| Who issues | Airline / carrier side of the shipment | Freight forwarder (house waybill) |
| Airline AWB number | Primary 11-digit XXX-XXXXXXXX |
Often still present (linked master); house has its own reference |
| DocAPI fields | awb_level: "mawb", awb_number |
awb_level: "hawb", awb_number + hawb_number when present |
One endpoint, one schema
You do not need separate “mawb ocr” and “hawb ocr” APIs. Upload the PDF or scan; read awb_level, awb_number, and optional hawb_number. Mod-7 applies to the airline 11-digit number; weight validators apply the same way.
{
"document_type": "air_waybill",
"awb_level": "hawb",
"awb_number": "071-12760786",
"hawb_number": "SHA-HKG-88421",
"airport_dep": "PVG",
"airport_dest": "LAX",
"validations": {
"awb_check_digit_ok": true,
"chargeable_gte_gross": true
},
"needs_review": false
}Illustrative house example—field names match the product schema; values are sample-shaped.
Who searches for what
- mawb to json / master air waybill data extraction — airline form → TMS / customs
- hawb to json / house air waybill data extraction — forwarder pre-alerts and consol paperwork
- freight forwarder document api — often HAWB-heavy, still needs Mod-7 on the airline number
What stays out of scope
Parcel courier labels are not MAWB/HAWB. Ocean B/L is a different family. If you already get clean FWB/EDI, keep it—this API targets the PDF/scan gap. More on the air waybill to JSON API page.
Accuracy
Any accuracy figures on DocAPI pages refer to a self-built ~31-document internal eval, not third-party certification. Real China→EU/US pre-alert scans will expand the set over time; production SLAs remain TBD.