Introduction

The Global Airport Concierge API v1 lets a partner price and book airport concierge services: Meet & Assist, Porter, Lounge Access and more, at over 500 airports.

Base URL: https://api-prod.globalairportconcierge.com/api/v1

GAC issues your credentials, and a sandbox base URL if you want one, when your integration is set up.

Getting started

1. Get access token — exchange your client_id and client_secret for a bearer token. Send it as Authorization: Bearer … on everything else. Tokens last a year, so cache it.
2. List services at an airport — find out what is available and at what rate.
3. Create quote — send the itinerary and get a price back. The booking is created in status quote.
4. Confirm quote — commit it. Status becomes booking and the customer is emailed.
5. Look it up later — by our id, our reference, or your own.

Endpoints are numbered in the order you would normally call them.

Booking lifecycle

         Create quote
              |
           [quote]  --- Replace / Reprice ---> [quote]
              |
        Confirm quote
              |
          [booking]
              |
        Cancel booking
              |
         [cancelled]

cancelled is terminal. Every other endpoint refuses a cancelled booking.

A quote is valid for one week. After that, reprice it before confirming.

Response envelope

Every endpoint except Get access token wraps its payload:

1
{ "message": "…", "status": 200, "responseTime": "125ms", "trace": [], "data": { } }

List endpoints add a pagination block and put an array in data:

1
"pagination": { "total_count": 7, "total_pages": 4, "current_page": 1, "limit": 2 }

Errors

Every error carries an error_code. Branch on error_code, not on the message. The code is a contract; the wording is ours to improve.

1
{
2
  "message": "No booking found with id 99999999. It may not exist, or it may belong to another company.",
3
  "status": 404,
4
  "responseTime": "22ms",
5
  "error_code": "booking_not_found",
6
  "data": { "errors": [] }
7
}

Validation failures add a top-level errors object keyed by field, and report every problem at once rather than stopping at the first:

1
{
2
  "message": "The currency field is required. (and 2 more errors)",
3
  "status": 422,
4
  "error_code": "validation_failed",
5
  "errors": {
6
    "currency": ["The currency field is required."],
7
    "journeys": ["At least one journey is required."]
8
  },
9
  "data": []
10
}

A 4xx other than 429 will not succeed on retry without a change on your side. 429 and 500 are the only ones worth retrying as-is.

Pricing inputs

Services are priced from the journey’s adult, child and infant counts and its bag counts. There is no per-service passenger override, so those counts must be accurate.

Lounge Access is the only service that charges infants, and only where the airport has a non-zero infant rate.

Rate limiting

300 requests per minute. Over that you get 429 rate_limit_exceeded. No Retry-After header is sent, so implement your own backoff rather than retrying immediately. If you expect sustained volume above this, talk to GAC before you go live.

Known quirks

These are real behaviours, documented so you do not lose a day to them.

Not available yet

• No webhooks. Nothing notifies you when a booking changes. Poll the booking endpoint for anything you need to stay current on.
• No idempotency key. A retried create makes a second booking. Send a unique settings.customer_reference every time and use it to detect and recover from duplicates.
• No date filter when listing bookings. Reconciliation means paging newest-first.
• Service discovery is partial. The catalogue endpoint returns only three of the bookable services. Ask GAC for the ids of the rest.

Last reviewed against the live API: 2026-08-24. Every example in this documentation is a real captured response, including the error ones.