Gozem Developer DocsDocs

Drive a trip through its lifecycle

Advance a sandbox trip from pending to completed yourself, so every webhook fires without waiting for a real courier.

Courier4 steps15 min

In production a trip advances because a courier is riding it live. In sandbox nobody is, so a trip you book sits at pending and the interesting webhooks never fire. That is where most integrations stop being testable.

One endpoint lets you drive the trip yourself. Every transition fires the same webhook a real trip would, and returns the trip as it stands afterwards.

Sandbox only. This endpoint does not exist in production, where trip state comes from the courier and the dispatch system.

Book a trip

Any sandbox trip will do. One dropoff is enough to reach every state.

Walk it forward

One action per transition. Pause between calls and check your handler saw the event before moving on.

assign picks an available sandbox driver for you, and the trip comes back carrying it, so there is no driver id to look up first.

stop-start and stop-complete apply to the next undelivered dropoff, so a multi-stop trip needs the pair once per stop before complete.

Confirm where it landed

Every action returns the trip, so the last one already told you where it landed. Compare that with your own records: a disagreement is a bug in your handler, and you now have a way to reproduce it as often as you like.

Then break it on purpose

The happy path is the easy half. cancel and expire are terminal, so each needs a fresh trip.

If you only ever test the happy path, the first real cancellation is a production incident. Two extra trips is a cheap way to avoid that.

The rest of the actions

Beyond the transitions above, the same endpoint takes:

Action Fires
update-location with lat and lon A driver location update, no state change
message with sender_type and text A driver message to your customer

Trip Lifecycle & Events lists which transitions are legal and which states are terminal.