API reference

Overview

Trip963 API is the B2C surface of a full flight stack — two services, one customer journey, fifteen endpoints.

If you run a travel website under your own brand, you should not have to rebuild search, cart, PNR and ticketing. Trip963 API gives your storefront a customer-safe contract: live flights, a fare the shopper can understand, and a booking that belongs only to that customer.

There is no gateway in front. Your storefront calls two hosts that both speak /v2. Auth lives on the user service. Everything about flying lives on booking.

Response

200

{
  "message": "Success",
  "data": {},
  "error": null,
  "timeStamp": "02-09-2026 15:30:00"
}

Base URLs

User (auth): https://user.aerolink.dev — /v2/auth/* Booking (everything else): https://booking.aerolink.dev — flights, cart, orders, travellers.

Tenant and storefront

Every request is tenant-routed before authentication, from the Host subdomain (default base domain trip963.com). A B2C storefront is not its own tenant — it runs on the founding tenant. Its subdomain must be listed as reserved, or the API rejects the call with 400 before any B2C code runs.

Authentication model

POST /v2/auth/login and POST /v2/auth/refresh are open. Everything else — including GET /v2/auth/me — needs Authorization: Bearer <accessToken>. The refresh token is never in the JSON. It is set as an HttpOnly cookie named refreshToken, host-only, so the API host must be one the storefront can send cookies to.

Success envelope

Every success is a ResponseModel. Timestamp format is dd-MM-yyyy HH:mm:ss.

Money the customer sees

Amounts are a nine-field B2cFare, already converted into the caller’s POS currency. No B2C payload contains agentPrice, costing, MRP, commission, markup, PCC or provider. total is what the customer pays — agent fare plus the storefront markup, charged once per booking.

Paging

Search endpoints return content, page, size, totalElements, totalPages, last. Query params are pageNum (default 0) and pageSize (default 10).