Skip to main content
If an existing API does not already exist for GNet integration, you can consume GNet’s object model for receiving trips. GNet requires one web service on the receive side to accept NEW, UPDATE, and CANCEL requests — all in a single endpoint. To provide status updates for incoming trips, you call providerUpdateStatusByResNo on GNet. This endpoint should be called whenever there is a change in Status, Driver Info, Vehicle Info, Charge line items, or Total.
The GNet team will work with your technical team to determine how to communicate with your web service, capture confirmation numbers, and capture error messages in case a trip has to be rejected.

​
Interpreting the payload

The web service receiving trip payloads from GNet must look at the affiliateReservation section to determine whether the payload is requesting a NEW trip, or whether it is an UPDATE or CANCEL for an existing trip. affiliateReservation.action tells your web service what needs to be done:

​
Key fields

​
Account number: who the trip is for

Read account.accountNumber on every incoming trip and attach the trip to that customer in your system. It answers a different question from affiliateReservation.requesterId: For most partners the two coincide: a transportation company farming you a trip is also the customer you bill. But not every GNet member is a transportation company. Brokers, travel-management companies, and travel-technology platforms send trips on behalf of their corporate clients, and those clients often want all their ground transportation to go to one specific operator — you. The sender and you agree on the client’s account number in your system; the sender puts it in account.accountNumber; your dispatchers see “this trip is for IBM” instead of “this trip is from a broker”. Systems that only look at the requester ID cannot tell those trips apart, and it is exactly those broker and TMC relationships that grow an integration’s volume. How GNet resolves the value you receive:
  1. The sender’s value wins. If account.accountNumber is present in the payload the sender submitted, it is delivered to you unchanged.
  2. Otherwise, your partner record fills it in. Every partner in the Connect dashboard has an Account Number field (“pink field”). When the sender leaves the field empty, GNet copies your Account Number for that partner into account.accountNumber before delivering the trip.
The set-up for every new partner is therefore the same: create a customer record for them in your reservation system, take the ID your system assigned, and enter it as their Account Number under Partners in Connect. account.accountName, callerName, callerEmail, and callerNumber travel alongside it and describe who booked.

​
Cancellations and rejections

Cancels are the highest-priority message on the network. A cancel that one side believes went through and the other never acted on means a driver is dispatched to a passenger who is not coming, and those get expensive. Both halves of the handshake have to be explicit.

​
Receiving a cancel

A cancel arrives at your endpoint as the same payload shape as a new trip, with affiliateReservation.action = "CANCEL" and your own affiliateReservation.providerResNo identifying the trip. Your endpoint’s HTTP response is the acknowledgement: Answer one or the other every time. Silently accepting a cancel you did not act on, or returning success: true before the trip is actually cancelled in dispatch, is the failure mode certification looks for.

​
Rejecting a new trip

You are not obliged to take every trip. Refuse anything your system cannot fulfil as sent — a pickup already in the past, a vehicle type you do not offer, an address you cannot resolve — by answering success: false with a specific message. The message is stored on the transaction and relayed to the sender, so “Vehicle type COACH is not offered” is worth far more than “Error”. If your system takes trips in first and decides later, send a REJECT status through providerUpdateStatusByResNo. Either form counts as a rejection; the synchronous one is preferred because the sender learns immediately.

​
Cancelling from your side

If you cannot perform a trip after taking it in, send REJECT or CANCEL through providerUpdateStatusByResNo while the trip is still BOOKING_REQUEST or CONFIRMED; GNet notifies the sender through their webhook and by email. Once the trip is ASSIGNED or later the platform refuses a provider-side cancel, and only the sender can cancel it.

​
Providing status updates

Once you have received and accepted a trip, push status changes back to GNet by calling providerUpdateStatusByResNo or providerUpdateStatusByTransactionId. Send an update whenever any of the following change:
  • Status Code (see Status Codes)
  • Driver / Chauffeur info
  • Vehicle info
  • Charge line items (fees)
  • Total amount

Webhook Callbacks

GNet relays these updates back to the original sender via real-time webhook callbacks.