Channel Partner API

The Channel Partner API is a two-way interface between Glacial Adventures and channel managers, property management systems and central reservation systems. Your system pushes rooms, rates and availability to Glacial; Glacial delivers confirmed bookings, modifications and cancellations back to your system in real time.

Inbound, you call four endpoints: room and rate-plan discovery, rate push, availability push, and no-show reporting. Outbound, Glacial POSTs booking events to an HTTPS endpoint you register with us.

Every inbound request is an HTTP POST with a JSON body and a Content-Type of application/json. There are no GET endpoints and no query parameters. The trailing slash on each path is optional.

Credentials are issued by Glacial. There is no self-service signup and no sandbox key you can mint yourself — every integration starts with an application and ends with a certification pass.

1. 1
   Apply

   Submit the Become-a-Partner form below. It's the only queue.

2. 2
   We review

   Our partnerships team replies within 2 working days, on WhatsApp or email.

3. 3
   Your partner account

   Approved partners receive an email invite. Set your password and sign in to the partner extranet.

4. 4
   Credentials & integration

   Your test-property hotel code and AuthCode are on your API Integration page, viewable whenever you need them. Integrate the flows in this documentation against the base URL shown above; your credentials identify you in the request body — there is nothing partner-specific in the URLs.

5. 5
   Certification & go live

   We verify rate, availability and booking flows together on your test property, then enable production pushes across your hotels. Endpoints, payloads and credentials do not change between test and production.

Two credentials, two channels.

Your sign-in is a personal account — we email you an activation link when you're approved, and you choose your own password. Your API credentials (hotel code + AuthCode) are never emailed and never sent over WhatsApp: they live on the API Integration page of your partner account — masked by default, viewable by you whenever you need them, with every reveal logged. Nobody from Glacial will ever ask you for your AuthCode. If a code is ever compromised, one message to us rotates it instantly without affecting any other property.

Inbound requests authenticate in the JSON body, not in headers. Every request carries an auth block with the property's hotel code and API key. There is no Authorization header, no signature and no OAuth exchange on the inbound leg.

{
  "auth": {
    "hotel_code": "GLH101",
    "api_key": "secret_token_value"
  }
}

The source code in the URL identifies you as a partner; the auth block identifies the property. Both are checked on every request, and a valid key for one property will not authenticate another.

API keys are shown once, at issue. Glacial does not store a form you can read back, so keep the key in your own secret store. Keys can be rotated on request; the previous key stops working the moment the new one is issued, so schedule a rotation for a quiet window.

Outbound booking delivery authenticates the other way round. Glacial sends a bearer token you nominate, in a standard Authorization header, so you can verify that a booking event genuinely came from us.

Authorization: Bearer <your_outbound_token>
Content-Type: application/json
Accept: application/json

Three identifier formats appear across the API. All of them are case-sensitive, and all of them are assigned by Glacial — never construct one yourself.

The meal component of a rate plan code is one of five values, always upper case:

Bookings carry a reservation reference in the form GL-<booking>-<property>, for example GL-2026-001-H101. Treat it as an opaque string: it is the value you echo back in /noshow/ and the key you store against your own booking record.

Every inbound response is HTTP 200, including failures. The body carries the outcome in a fixed envelope; branch on success, never on the HTTP status. A non-200 status means the request never reached the gateway — a proxy, a network fault or a malformed body — and should be retried rather than parsed.

{
  "success": false,
  "code": "AUTH_FAILED",
  "message": "invalid api_key"
}

On success, code is an empty string and message is a human-readable summary. Discovery adds a rooms array beside the envelope; the batch endpoints add nothing.

Rate and inventory pushes are batches, and a batch is not all-or-nothing. Rows are applied independently: valid rows are written, invalid rows are itemised in the message by their zero-based index in the array you sent. The batch reports success as long as at least one row applied, so a 200 with success true still deserves a look at message.

{
  "success": true,
  "code": "",
  "message": "2 rows applied; 14 dates; 1 rows failed: #2 INVALID_ROOM"
}

When every row fails, success is false and code carries the first failing row's code. Because indexes are zero-based, #2 is the third element of the array.

Dates are YYYY-MM-DD and every range is inclusive of both ends: start_date 2026-09-01 with end_date 2026-09-07 writes seven nights. A range whose end_date precedes its start_date fails the row with INVALID_RANGE.

Dates in the past are skipped, not failed. A range that straddles today writes the future half, reports the skipped count in message, and still counts as applied. A range entirely in the past writes nothing and applies no row — which is a success with zero rows applied, not an error.

A single row may span at most 400 days; a longer range fails that row with RANGE_TOO_LONG. There is no hard cap on rows per request, but keep a request to roughly 500 written dates in total — rows multiplied by nights — and split larger updates across several calls. Long single ranges are cheaper than many one-night rows covering the same period.

Rate rows may carry an ota_code to target a single channel. Leave it null or omit it and the rate applies to every channel — this is what almost every integration wants. Send a value and the row is applied only if it matches the OTA code assigned to your link; a row naming any other channel is silently skipped and counted in message as foreign-OTA skipped, not reported as a failure.

Amounts are in INR and are per room, per night, for the room's default occupancy. Extra adult and child amounts are surcharges on top of that base, not replacements for it.

When a booking is confirmed, changed or cancelled at Glacial, we POST a JSON event to the bookings endpoint you register during onboarding. The endpoint must be HTTPS and reachable from the public internet.

Each request carries your bearer token in an Authorization header and expects a JSON acknowledgement. Requests time out after ten seconds by default.

{
  "event": "create",
  "reservation_ref": "GL-2026-001-H101",
  "hotel_code": "GLH101",
  "sent_at": "2026-09-01T10:15:00+05:30",
  "booking": {
    "reference": "GL-2026-001",
    "created_at": "2026-09-01T10:12:00+05:30",
    "guest": {
      "given_name": "Asha",
      "surname": "Menon",
      "salutation": "Ms",
      "phone": "+910000000000",
      "email": "guest@example.com"
    },
    "comments": [
      "Late check-in requested",
      "Channel booking GL-2026-001"
    ]
  },
  "stays": [
    {
      "stay_ref": "5001",
      "room_code": "R55",
      "room_name": "Deluxe Room",
      "rate_plan_code": "R55_CP",
      "rate_plan_name": "Deluxe Room CP",
      "rooms": 1,
      "checkin": "2026-09-01",
      "checkout": "2026-09-05",
      "guests": {
        "adults": 2,
        "children": 1,
        "infants": 0
      },
      "amount": "18000.00",
      "currency": "INR",
      "resolution": "hint"
    }
  ],
  "payment": {
    "status": "prepaid",
    "paid_amount": "18000.00",
    "total_amount": "18000.00"
  }
}

reservation_ref is stable across all three events for a given reservation, so it is the key to store and match on. sent_at and event are stamped at delivery time; everything else describes the reservation's current state.

No card data is ever sent. The payment block reports what has been collected and what is owed, nothing more.

To acknowledge an event, return HTTP 200 or 201 with a JSON body containing success true and your own reference for the booking:

{
  "success": true,
  "booking_id": "PMS-REF-789012"
}

To reject a booking your system genuinely cannot accept — an unmapped room category, a closed property — return HTTP 400 or 422 with success false and a message. The event is recorded as BOOKING_REJECTED for the operations team to resolve, and is not retried.

{
  "success": false,
  "message": "Room category R55 is not mapped in the PMS"
}

Transport failures and the statuses 429, 500, 502, 503 and 504 are retried up to three attempts with an increasing delay, honouring Retry-After when you send one. Anything else — a non-JSON body, a missing booking_id, another 4xx — is recorded as a failed delivery and surfaced to the operations team rather than retried automatically.