Bookings

List bookings for reconciliation and act on them from your own system. Actions require the booking:write scope and are keyed by rynt_booking_id (from the list or a webhook payload).

Listing & reconciliation

curl "https://api-dev.rynt.ae/api/partner/v1/bookings?limit=50&updated_since=2026-08-01T00:00:00Z" \
  -H "Authorization: Bearer pk_test_…"

Use updated_since to catch anything that changed while your webhook endpoint was down — this is your safety net for missed webhooks.

Actions

Action	Effect
`POST /bookings/{id}/approve`	Approve a request-to-book — captures the held payment
`POST /bookings/{id}/reject`	Reject — releases/refunds the hold. Body: `{ "reason": "…" }`
`POST /bookings/{id}/cancel`	Cancel a booking. Body: `{ "reason": "…" }`
`POST /bookings/{id}/pickup`	Confirm pickup / check-in
`POST /bookings/{id}/return`	Confirm return / check-out

# approve
curl -X POST .../bookings/<id>/approve -H "Authorization: Bearer pk_test_…"

# reject with a reason
curl -X POST .../bookings/<id>/reject \
  -H "Authorization: Bearer pk_test_…" -H "Content-Type: application/json" \
  -d '{"reason":"car unavailable"}'

A successful action returns:

{ "data": { "rynt_booking_id": "…", "booking_number": "BK-…" }, "request_id": "req_…" }

If the booking isn't in a valid state for the action (e.g. approving one that isn't awaiting approval) you get a 400 with a clear message.

📘
Source of truth
RYNT always owns the booking record and the payment. Your actions drive RYNT's existing flows (approve → capture, reject → release), and each one emits the matching webhook (booking.approved, booking.rejected, …).