The travel-tech house behind InnoTravelTech, ReservationHub, TripGic, and Inno Message
Developers

TripGic API — developer documentation

Build travel into your product. TripGic is a unified travel API that aggregates flights, hotels, cars, activities and dynamic packages from many suppliers behind a single REST interface — one integration instead of dozens.

Scaffold. This page documents the API at a high level and the conventions it follows. Endpoint-level details — exact paths, parameters, response schemas and your base URL — are issued with your API credentials on onboarding. The quickstart below is a representative pattern, not a live endpoint.

Overview

TripGic exposes travel content and booking operations through one REST API. Instead of integrating each GDS, bed-bank, low-cost carrier and activity supplier yourself, you call a single, normalised interface and TripGic handles aggregation, mapping and supplier routing behind it. Typical use cases include powering an OTA or agency front end, embedding booking into a corporate or vertical app, and building a custom workflow on maintained supplier connections (see build vs buy).

Access & authentication

Access is granted on onboarding. Request credentials and you will receive an API key, the base URL for your environment, sandbox access for testing, and the full endpoint reference.

Authenticate every request by sending your API key as a bearer token in the Authorization header over HTTPS. Never expose your key in client-side code; call the API from your server.

Authorization: Bearer YOUR_API_KEY
Accept: application/json
Content-Type: application/json

API conventions

The API follows predictable, standard REST conventions so it behaves the way experienced developers expect:

  • Transport & format. REST over HTTPS; JSON request and response bodies; UTF-8.
  • Versioning. The API is versioned in the URL path (for example a /v1/ prefix); your onboarding pack confirms the current version and base URL.
  • Authentication. API key as a bearer token in the Authorization header (above).
  • Pagination. List responses are paginated; pass page/limit parameters and follow the paging metadata returned with each list.
  • Rate limiting. Requests are rate limited per key; responses include rate-limit headers, and exceeding the limit returns HTTP 429. Back off and retry.
  • Idempotency. Booking and other state-changing calls support an idempotency key so retries do not create duplicates.
  • Currencies & locales. Requests accept currency and language parameters; pricing is returned in the requested currency where supported.

Resources

The API is organised into resource areas. The authoritative list of endpoints, parameters and fields is in the reference issued with your credentials; at a high level it covers:

  • Search — query availability and pricing across suppliers for a journey.
  • Flights — air search, fare rules, ancillaries and ticketing.
  • Hotels — hotel search, room and rate details, and booking.
  • Cars — car-hire search and booking.
  • Activities — tours and activities search and booking.
  • Packagesdynamic packaging across components.
  • Bookings — create, retrieve, cancel and manage bookings.
  • Webhooks — subscribe to asynchronous booking and status events.

Quickstart

The pattern below is representative — it shows the shape of a typical call (authenticated, JSON in, JSON out), not a live endpoint. Replace the base URL, path and fields with the values from your onboarding reference.

# Representative request shape (illustrative only)
curl -X POST "https://<your-base-url>/v1/search" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "product": "hotel",
    "destination": "DXB",
    "check_in": "2026-10-01",
    "check_out": "2026-10-04",
    "occupancy": [{ "adults": 2 }],
    "currency": "USD"
  }'
# Representative response shape (illustrative only)
{
  "request_id": "…",
  "currency": "USD",
  "results": [ /* normalised offers across suppliers */ ],
  "paging": { "page": 1, "limit": 25, "total": 0 }
}

Errors

The API uses standard HTTP status codes and returns a consistent JSON error envelope so failures are easy to handle programmatically.

  • 200 success · 201 created
  • 400 invalid request · 401 missing/invalid key · 403 not permitted · 404 not found
  • 409 conflict (for example a duplicate idempotent request) · 422 validation error
  • 429 rate limited · 5xx service error (retry with back-off)
# Representative error envelope (illustrative only)
{
  "error": {
    "code": "validation_error",
    "message": "Human-readable description of what went wrong",
    "details": [ /* field-level issues, when applicable */ ]
  }
}

Support

For credentials, the full endpoint reference, sandbox access or integration help, contact our team or email sales@innovatesolution.com. To understand where the API sits in the wider platform, see TripGic and ReservationHub.