A reservation holds a spot until held_until. Once the vehicle is in its spot, you check it in. When it drives away, you check it out. Those two calls are how the staging area knows which spots are taken, so send them as soon as each thing happens.
This guide starts from a held reservation, res_8f2c41, for vehicle rt-0417 at sa_norreport. To get one, see Holding a spot.
Check in
Check in when the vehicle is parked in the spot named in spot, at location. It can check in any time while the reservation is held, early too. Do it before held_until, or the hold runs out.
curl -X POST https://api.golanoo.com/v1/reservations/res_8f2c41/check_in \ -H "Authorization: Bearer $LANOO_API_KEY" \ -H "Idempotency-Key: 9b2d6e3f-7a41-4c0e-8f15-3d9a6c2b7e80"The response is the reservation, now checked_in:
{ "id": "res_8f2c41", "object": "reservation", "vehicle_id": "rt-0417", "staging_area": "sa_norreport", "spot": "2", "location": { "lat": 55.6838, "lng": 12.5721 }, "status": "checked_in", "arrive_by": "2026-11-02T14:02:00Z", "held_until": "2026-11-02T14:07:00Z", "checked_in_at": "2026-11-02T14:01:37Z", "leave_by": "2026-11-02T14:46:37Z", "checked_out_at": null, "cancellation_reason": null, "metadata": {}, "created_at": "2026-11-02T13:51:12Z"}leave_by is when the vehicle has to be gone. It is checked_in_at plus the staging area's max_stay_minutes, which is 45 at Nørreport, or the start of a planned closure of the spot, if that comes first. Read it from the response rather than working it out yourself, and plan the vehicle's next move around it.
Some staging areas have no limit, such as one where vehicles wait out the night. There max_stay_minutes is null, and so is leave_by, unless a closure of the spot is planned. The vehicle may stay as long as it likes.
If the staging area closes suddenly, leave_by moves to the moment it closed, and you receive reservation.must_leave. See When a staging area closes.
Send an Idempotency-Key every time
Send an Idempotency-Key header on every POST and PATCH, with a new unique value, such as a UUID, for each new action. If the call times out and you are not sure it arrived, send it again with the same key and the same body. It takes effect once.
Without a key, a retry of a check-in that already went through fails with reservation_not_held, because the reservation is no longer held. With the key, the retry gets the first answer back. Keys are kept for 24 hours. The same key with a different body is refused with idempotency_key_reused.
When check-in fails
Both errors below return HTTP 409 with an error of type conflict. Branch on code. A reservation id that does not belong to your fleet fails with 404 and not_found, on this call and every other call on a reservation.
{ "error": { "type": "conflict", "code": "hold_expired", "message": "The hold ran out before the vehicle checked in. Reserve again." }}hold_expired: the vehicle did not check in beforeheld_until, and the spot went to whoever was next. The reservation is nowexpired. If the vehicle still needs somewhere to wait, reserve again. The new reservation may be for another spot, or the staging area may be full.reservation_not_held: the reservation is already checked in, checked out or cancelled. Get the reservation to see itsstatus. If it iscancelled,cancellation_reasonsays why.
If your vehicle is running late, change arrive_by before the hold runs out, rather than letting it expire. See Reservations.
Check out
Check out as soon as the vehicle leaves its spot. The spot frees up for whoever is next.
curl -X POST https://api.golanoo.com/v1/reservations/res_8f2c41/check_out \ -H "Authorization: Bearer $LANOO_API_KEY" \ -H "Idempotency-Key: 2c8f4a7e-1b3d-4e6a-9f05-7d2e8b1c6a39"The response is the reservation with status set to checked_out and checked_out_at set to when you checked out. A vehicle past leave_by checks out the same way.
Until you check out, the vehicle still has a reservation that is checked in. Reserving another spot for it fails with vehicle_already_reserved.
If the reservation is not checked in, check-out fails with HTTP 409 and reservation_not_checked_in. Either it is still held, and you cancel it instead, or it has already ended.
Overstaying
If a checked-in vehicle is still there after leave_by, we send a reservation.overstayed event to your webhook endpoint, once, if it asks for that event. The reservation in the event is the one that ran over. We send nothing more. What happens next, if anything, is for the staging area's owner to decide.
When you receive it, move the vehicle on and check it out once it has left. To receive events at all, register an endpoint; see Receiving webhooks.
Cancel or check out
The two calls end a reservation at different points. Use the one that matches its status.
| Status | The vehicle | Call | The reservation becomes |
|---|---|---|---|
held | Has not arrived, and will not | POST /reservations/{id}/cancel | cancelled, with cancellation_reason requested |
checked_in | Is in its spot and leaves | POST /reservations/{id}/check_out | checked_out |
Cancelling a reservation that is not held fails with reservation_not_held: a checked-in vehicle checks out instead. Checking out a reservation that is held fails with reservation_not_checked_in: cancel it instead.
curl -X POST https://api.golanoo.com/v1/reservations/res_8f2c41/cancel \ -H "Authorization: Bearer $LANOO_API_KEY" \ -H "Idempotency-Key: 3e8b5c2a-9f14-4d7e-a0c6-5b2f8e1d9a73"Cancel as soon as you know the vehicle is not coming, so the spot goes to someone who needs it.
Next
- Receiving webhooks, to hear about expired holds, closures and overstays.
- Reservations, every field and error.