Designing a Cross-Border Airport Transfer Checklist as Structured Data

A developer outlined a structured-data approach for cross-border airport transfers, modeling Hong Kong Airport to Shenzhen and Dongguan bookings as a validated JSON and TypeScript schema rather than free-form chat requests. The design captures arrival, destination, passenger, luggage, and stop fields, enforces rules such as a six-passenger Alphard limit, and separates published reference fares (starting at RMB 800 to Shenzhen) from confirmed bookings. The writeup stresses that border procedures should carry a visible uncertainty note rather than being treated as a deterministic API response.

Travel logistics look simple until one missing field breaks the plan. A destination such as “Shenzhen” is not enough for a driver, dispatcher, or booking form. The useful design problem is to turn a human request into structured data that can be validated before a vehicle is assigned. This post uses a Hong Kong Airport to Shenzhen or Dongguan transfer as a practical example. CrossBorderHK operates the referenced service; this is an engineering-oriented adaptation, not a neutral price comparison. I used AI assistance for outlining and copy editing, and the operator must verify current operational details before publishing or using the data. A minimum request should capture: A small JSON object is easier to validate than a paragraph copied from a chat message: { "arrival": { "date": "2026-10-18", "flight": "CX000", "airport": "HKG" }, "destination": { "city": "Shenzhen", "district": "Nanshan", "address": "Hotel name and entrance" }, "passengers": 4, "children": 1, "luggage": { "count": 4, "size": "24in" } , "stops": , "needs": "child-seat" } For Dongguan, replace district with township and include the industrial park or factory gate. This prevents a city-level quote from hiding the last-mile problem. Validation should happen before dispatch. A lightweight TypeScript example: type TransferRequest = { arrival: { date: string; flight: string; airport: "HKG" }; destination: { city: "Shenzhen" | "Dongguan"; district?: string; township?: string; address: string }; passengers: number; children: number; luggage: { count: number; size?: string } ; stops: string ; }; function validate r: TransferRequest { if r.arrival.flight || r.destination.address throw new Error "Flight and exact address are required" ; if r.destination.city === "Shenzhen" && r.destination.district throw new Error "Add the Shenzhen district" ; if r.destination.city === "Dongguan" && r.destination.township throw new Error "Add the Dongguan township" ; if r.passengers < 1 || r.passengers 6 throw new Error "Check vehicle passenger capacity" ; } The six-passenger limit reflects the normal Alphard arrangement described by the operator: seven seats including the driver. Keep this rule in configuration so the UI and dispatch service share one source of truth. A quote object should separate a published reference value from a confirmed booking: { "currency": "RMB", "referenceFare": 800, "destinationScope": "listed Shenzhen districts", "includes": "driver", "fuel", "standard tolls" , "requiresConfirmation": "waiting", "night surcharge", "extra stops", "border procedure" , "status": "reference" } The published Hong Kong Airport to Shenzhen reference starts at RMB 800 / HKD 930. The listed Hong Kong to Dongguan route starts at RMB 1,200 / HKD 1,400 for some townships. Treat both as starting references. The final address, date, vehicle, waiting, and route conditions still need written confirmation. Avoid representing border behavior as a deterministic API response. Passenger and luggage procedures can depend on permits, checkpoint, documents, lane, and on-site officer instructions. Store the planned procedure together with a visible uncertainty note. The last step is a message a traveler can review: Please quote a private transfer from HKG to district/township and exact address . Flight: number/date . Passengers: count, children . Luggage: count and dimensions . Stops: list . Please confirm total fare and currency, inclusions, waiting and overtime rules, cancellation terms, and planned border procedure. This exposes assumptions before payment and gives a dispatcher enough context to correct the data instead of guessing. A useful test matrix includes: The test should verify that the interface asks for clarification, preserves the original request, and never silently converts a reference fare or estimated time into a guarantee. Structured data does not remove uncertainty from cross-border travel. It makes the uncertainty visible early enough for a traveler, dispatcher, and driver to act on it.