Partner API

How this compares to PKFare, Duffel & Amadeus

These names are different layers: some sell raw supplier connectivity, others wrap many carriers behind one API. Airhux is a multi-tenant travel platform: you integrate as a tenant, apply your commercial rules (markup), and call our HTTP API. In this product, flight shopping is backed by Amadeus flight offers (industry-standard JSON offer objects). Partner routes under /v1/partner cover server-to-server steps (e.g. holding a priced offer as a selection); search uses a separate public route so browsers and backends can load results the same way our web apps do.

Flight flow: search → offer → selection

1. Search — GET https://patner.gomyticket.com/v1/flights/search. Returns a JSON array of flight offers (Amadeus-style objects: itineraries, segments, price, travelerPricings, etc.). No Partner API key on this route; pass your tenantId so tenant markup rules apply to displayed totals.
2. Pick an offer — read id (offer id) from the chosen array element. Prefer keeping the full offer JSON in memory for the next step.
3. Create a selection — POST https://patner.gomyticket.com/v1/partner/flights/selections with Authorization: Bearer keyId:secret. Send offerData with the full offer object when possible — that avoids a second supplier search and fixes issues where offer ids can shift between searches.
4. Retrieve the selection — GET https://patner.gomyticket.com/v1/partner/flights/selections/:id returns the stored priced offer and metadata (subject to server TTL).

Full booking (passengers, payment, ticketing) is handled by the same platform flows as our apps (wallet, payments, etc.). The Partner API surface today focuses on health, selections, and webhooksfor events — not a duplicate "Duffel order" endpoint on /v1/partner.

Search: GET /v1/flights/search

Public route (optional user JWT). Use query parameters below. IATA airport codes, ISO dates YYYY-MM-DD.

Response: JSON array of offers. When tenantId is present, price.total / grandTotal reflect selling price after markup; original supplier total may appear as supplierTotal.

curl -sS \
  "https://patner.gomyticket.com/v1/flights/search?origin=MAD&destination=BOS&departureDate=2026-06-15&adults=1&tenantId=<your-tenant-uuid>&channel=B2C"

Create selection: POST /v1/partner/flights/selections

Body (JSON). If offerData is omitted, the server looks up the offer again using offerId and the same search dimensions — that can fail if ids moved, so always send offerData in production when you have it.

Success: { "selectionId": "<uuid>" }. Send X-Idempotency-Key on POST to safely retry.

curl -sS -X POST "https://patner.gomyticket.com/v1/partner/flights/selections" \
  -H "Authorization: Bearer <keyId>:<secret>" \
  -H "Content-Type: application/json" \
  -H "X-Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000" \
  -d '{
    "offerId": "1",
    "offerData": { /* paste full offer from GET /v1/flights/search response */ },
    "origin": "MAD",
    "destination": "BOS",
    "departureDate": "2026-06-15",
    "adults": 1
  }'

Get selection: GET /v1/partner/flights/selections/:id

Returns a JSON object with selectionId, offerId, pricedOffer (the stored offer), and search dimensions. Selections expire after a server-defined TTL; if missing, repeat search + create selection.

Partner authentication & idempotency

Use on /v1/partner/… only:

Authorization: Bearer <keyId>:<secret>
Content-Type: application/json

# Mutations (e.g. create selection):
X-Idempotency-Key: <uuid>
Idempotency-Key: <uuid>

Partner routes summary

API root for this build: https://patner.gomyticket.com/v1/partner

Scopes on the key typically include flights:selections and flights:book.

Enabling & rotating keys

• Enablement: the platform Super Admin approves Partner API for your tenant. The platform tenant cannot use Partner API keys this way.
• Rotate (tenant admin JWT): POST https://patner.gomyticket.com/v1/tenants/{tenantId}/partner-api/rotate — path tenant id must match your JWT. Returns a new keyId:secret once.