> ## Documentation Index
> Fetch the complete documentation index at: https://docs.grdd.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Certification

> What GNet checks before an integration goes live, and how to rehearse it

Every integration is certified with a short, scripted exchange of **real** test trips before it goes live — there is no sandbox on GNet, so the trips are real GNet messages sent from GNet's `gnettest` account and cancelled afterwards. Certification usually completes within a day, and go-live follows immediately: there is no separate launch step.

Farm In (receiving) and Farm Out (sending) are certified **separately**. They do not share events, so you can certify and go live with one, run it with real partners for as long as you like, and add the other later. Members who plan to do both usually find it easiest to finish both while the same engineers are engaged.

<Note>
  Expect small tweaks after go-live. Partners send addresses, notes, and passenger details in every format imaginable; GNet catches the ones that break and you will adjust for a few of them. That is normal and does not affect certification.
</Note>

## Farm In certification

GNet sends a handful of test reservations to your endpoint and then walks them through the exchanges below. You process them, we compare notes on what each side recorded, and if they match you are certified.

<Steps>
  <Step title="Receive the trips">
    Several `NEW` reservations arrive at your endpoint. Each must be created in your system with the details intact — addresses, pickup times, passengers, vehicle type — and answered with `success: true` and your reservation number. You then confirm each one through [`providerUpdateStatusByResNo`](/platform-api/provider-updates/update-by-resno).
  </Step>

  <Step title="Status updates">
    On the same reservations, you send the dispatch lifecycle back: `CONFIRMED`, `ASSIGNED`, `EN_ROUTE`, `ON_LOCATION`, `PASSENGER_ON_BOARD`, `COMPLETE`, and `CLOSE` with the final charges. GNet checks that every status arrives, is one of the [documented codes](/platform-api/reference/status-codes), and carries driver, vehicle, and fee detail where your system has it.
  </Step>

  <Step title="Cancels — both ways">
    GNet cancels one of the confirmed trips. Your endpoint receives `action = "CANCEL"` and must answer explicitly: `success: true` once the trip is cancelled in your dispatch, or `success: false` with a message if it cannot be. Both answers pass; a cancel that is acknowledged but not acted on, or acted on but not acknowledged, does not. This is the check GNet weights most heavily — a missed cancel sends a driver to a passenger who is not coming. See [Cancellations and rejections](/platform-api/receiving-reservations#cancellations-and-rejections).
  </Step>

  <Step title="Bad reservations">
    GNet sends reservations your system should refuse: one with a pickup time already in the past, and one asking for a vehicle type you do not offer. The pass is a clean rejection — `success: false` with a message that says why, or a `REJECT` status afterwards. Accepting either one is the failure, because it means a bad trip would sit on a dispatcher's board.
  </Step>

  <Step title="Account number">
    On each trip, `account.accountNumber` must land on the right customer record in your system. For the test partner that is the Account Number you set for `gnettest` under *Partners* in Connect. See [Account number: who the trip is for](/platform-api/receiving-reservations#account-number-who-the-trip-is-for) — treating this field as the sender's GNet ID is the most common thing certification sends people back to fix.
  </Step>
</Steps>

### Rehearse it yourself first

If you have an API Gateway account or connect as a reservation platform, the **GNet Robot** in the [Connect dashboard](https://dashboard.grdd.net/dashboard/integration-robot) runs the same exchanges on demand, and shows you the exact status call it is waiting for at each step. Its test cases map onto the list above:

| Certification check               | Robot test case                                                                        |
| --------------------------------- | -------------------------------------------------------------------------------------- |
| Receive the trips, status updates | *Full lifecycle*                                                                       |
| Cancels                           | *Cancel after confirm* — records whether your system accepted or rejected the `CANCEL` |
| Updates to a live trip            | *Pickup update after confirm*                                                          |
| Bad reservations                  | *Past pickup* and *Unsupported vehicle type* — the pass is a rejection                 |

A run that ends with your system holding a live reservation (a cancel your system refused, or one that never reached it) says so in red, with the reservation and transaction IDs, so you can cancel it by hand.

## Farm Out certification

You send test reservations to a GNet test provider; GNet checks how they were formatted and then changes their statuses so you can confirm the changes reach your webhook.

<Steps>
  <Step title="Callback webhook registered">
    Your listener must be registered before the first trip is sent — it is where every status change, driver assignment, rejection, and cancellation for trips you farm out comes back. See [Webhook Callbacks](/platform-api/reference/webhook-callbacks).
  </Step>

  <Step title="Addresses">
    The part of Farm Out certification that most often fails. Every address must be sent both as one full line and broken into street, city, state, zip, and country; airports must use IATA codes with airline code and flight number. See [Sending Reservations](/platform-api/sending-reservations).
  </Step>

  <Step title="Status changes reach you">
    GNet moves the test trips through the lifecycle from the provider side. Each change must arrive at your webhook and be reflected on the trip in your system, including driver and vehicle detail and the closing charges.
  </Step>

  <Step title="Cancel handshake">
    You cancel a test trip with [`cancelTripByTransactionId`](/platform-api/reservations/cancel-by-transaction-id) and handle both answers: `OK` (the provider accepted) and the provider's error text (they refused — the trip is still live and needs follow-up).
  </Step>

  <Step title="Account number">
    If you send trips on behalf of your own clients — you are a broker, a travel-management company, or a travel platform — `account.accountNumber` must carry the client's account number *in the provider's system*, agreed with that provider, so they know who the trip is for.
  </Step>
</Steps>

## After certification

Results and any follow-ups are shared by email with everyone on the integration thread. Go-live is immediate once both sides agree the trips match. A joint announcement, if wanted, comes after the integration is complete in both directions and is never a blocker.

<Card title="Contact Support" icon="headphones" href="mailto:support@grdd.net">
  To schedule certification, or if a check does not pass and you want to talk it through.
</Card>