NAZMUL

FitsAir

API Integration

Maintenance
2022
Integration
FitsAir
005
Year

2022

Duration

3 months

Team

2 engineers

Role

Integration Engineer

Real-time airline API inside an OTA microservice architecture

Overview

The FitsAir integration connects a regional airline's proprietary booking API into the Trabill OTA platform as a dedicated microservice. The integration handles the full booking lifecycle: search availability, price validation, seat selection, booking creation, PNR confirmation, and cancellation. Because FitsAir's API has rate limits and occasional downtime, the integration is built defensively — all outbound calls go through a circuit breaker, failed bookings are queued for retry with exponential backoff, and webhook events from FitsAir trigger async status updates in the OTA. The microservice exposes a clean internal API to the rest of the OTA system, fully abstracting FitsAir's proprietary protocols.

Key Achievements

Full booking lifecycle: search → validate → book → confirm → cancel

Circuit breaker pattern prevents cascade failures during FitsAir outages

Bull-powered retry queue with exponential backoff for failed API calls

Webhook receiver for real-time PNR status updates from FitsAir

Clean internal REST API fully abstracts FitsAir's proprietary schema

Comprehensive request/response logging for dispute resolution

Technical Challenges
01
API rate limiting and timeouts

FitsAir's API enforces strict rate limits and occasionally times out under load, causing booking failures to cascade into the main OTA system.

SOLUTION →Implemented a circuit breaker that opens after 5 consecutive failures, pausing all requests for 30 seconds before probing. This prevents OTA degradation while FitsAir recovers.
02
Guaranteed booking delivery

A network drop mid-booking could leave a booking in a partially confirmed state with no reliable way to reconcile.

SOLUTION →Introduced idempotency keys on all booking requests. If a request fails after FitsAir has confirmed, the retry returns the existing PNR instead of creating a duplicate booking.
03
Schema mapping complexity

FitsAir uses a bespoke XML-based schema with airline-specific field names that don't map cleanly to the OTA's internal booking model.

SOLUTION →Built a bidirectional mapping layer with strict TypeScript types on both sides. Any unmapped field throws at compile time — making schema drift a build error, not a runtime surprise.
metrics.json
99.95%
Availability
<150ms
Avg Latency
96%
Retry Success Rate
100%
Webhook Accuracy
200+
Daily Bookings
<30s
Timeout Recovery
Technology

Service

Node.jsTypeScriptExpress microservice

Resilience

Bull job queueCircuit breakerExponential backoff

Database

PostgreSQL (bookings)Redis (job queue store)

Transport

Axios (outbound)Webhooks (inbound)REST internal API

Infra

Docker containerNginx sidecarHealth checks
Development Timeline

PHASE 01API Analysis

FitsAir API docs reviewAuth flowSchema mapping designError catalogue