Skip to main content

Search connected GDS providers for available flights on a route and date, for one airline tenant per call.

POST 
/api/v1/FlightBooking/Search

Ticketing strangler Phase 1 (2026-09-02, docs/MICROSERVICES_DECOMPOSITION.md) -- exposes search, which ondgo.gds already implements and tests (CraneGdsAdapter/ VidecomGdsAdapter.SearchAsync) but nothing had ever called through an externally-reachable endpoint. Deliberately shaped to match the response contract the one confirmed real consumer -- ondgo-frontend's agency POS module (libs/ondgo-service-flight) -- already parses from the legacy TicketOSController.GetFlightAvailability action (data.craneResponse[].craneResponse. body.getAvailabilityResponse.availability..., data.videcomResponse), confirmed by direct read of libs/ondgo-service-flight/.../choose-flight.component.ts, not assumed. That legacy action always queries every configured Crane airline AND Videcom unconditionally and merges both -- this endpoint mirrors the two-provider fan-out (calling ondgo.gds's Search for both), but is scoped to the ONE airline TenantId the caller supplies (matching Book/Cancel's existing per-tenant model) rather than looping over every airline the platform knows about, a deliberate, stated scope difference -- searching across multiple airlines in one call would need its own design, not assumed here.

Crane's response is real, typed, camelCase JSON (CraneGdsAdapter.cs's CamelCaseJsonOptions fix, same date) -- deserialized here into a JsonElement and embedded directly, matching the legacy shape exactly with no local re-modeling of Crane's deeply nested response tree. Videcom's RawResponseJson is passed through as-is (already a JArray of {departureAirport, arrivalAirport, departureDate, success, response|errorMessage} entries, camelCase by construction since VidecomGdsAdapter builds it with Newtonsoft JObject/JRaw) -- this does NOT match the legacy videcomResponse.xmlResponse field the frontend's (partially commented-out, likely not fully live) Videcom-parsing code reads. Stated plainly, not silently assumed compatible: Videcom search response-shape parity is NOT closed by this endpoint and needs its own investigation if/when it matters.

Track C5 note (docs/AGENCY_IMPLEMENTATION_TASKLIST.md): this comment is split into a short summary tag plus this remarks tag specifically because Swashbuckle maps the summary tag to the OpenAPI operation summary, which docusaurus-plugin-openapi-docs then uses to name the generated MDX file -- the original single giant summary tag was long enough to exceed the filesystem's ENAMETOOLONG limit. Idiomatic XML-doc convention (short summary, longer remarks) turned out to double as the fix.

Request​

Responses​

OK