RideLoop

Developers

Everything the storefront does, your code can do too.

One REST API over the same records the operator portal writes to — fleet, bookings, tours and packages. Idempotent writes and signed webhooks from the day your plan includes API access.

Read the docsSee the detail

Resources

Two objects, and the rest hangs off them.

If you understand the fleet and a booking, you understand the API — everything else is a read on one of those two.

Fleet
Your published bike categories, guided tours and holiday packages in one list — the same catalog the storefront shows. Book against any id it returns.
Bookings
A bike-category rental, a guided tour and a holiday package are one object with a type. Runs the exact pricing, waiver and payment pipeline the storefront uses.
Payments
Every charge and refund recorded against a booking, plus a payment-link endpoint to collect an outstanding balance after the fact.
Webhooks
Signed, retried deliveries so you don’t have to poll for a status change — see below.

Webhooks

10 events, and you don’t have to poll.

Every event carries the whole object, signed with an HMAC header. A failed delivery retries automatically — immediately, then roughly a minute, five minutes, thirty minutes and two hours later — before it’s marked exhausted. One endpoint per account for now, stated plainly in the docs.

booking.created
A new booking was created.
booking.confirmed
A booking was paid or otherwise confirmed.
booking.cancelled
A booking was cancelled — any refund due is already issued by the time this fires.
booking.completed
A rental, tour or package finished.
booking.rescheduled
A guest accepted a Ride Guarantee weather reschedule.
payment.received
A deposit or balance payment came in.
payment.failed
A payment attempt failed.
payment.refunded
A refund was issued.
dispute.created
A card dispute was opened.
dispute.closed
A card dispute was resolved.

Getting started

A real developer portal, not a README.

A full endpoint reference, a getting-started guide, a machine-readable OpenAPI spec and generated request examples in cURL, TypeScript, Python, PHP and Go.

Keys and scopes
Four scopes — read bookings, write bookings, create payment links, read fleet — granted per key, so an integration only does what it needs.
Honest docs
Current limits — one webhook endpoint per account, no versioning beyond the v1 path prefix — are stated in the docs themselves, not discovered in production.
Rate limits
150 requests a minute per key, on a sliding window. Every response carries X-RateLimit-* headers so you can see your budget without guessing.
Idempotency
Every write takes an Idempotency-Key, so a retried checkout returns the original result and cannot double-book a frame.

Already connected

If the storefront already does it, there is nothing to build.

The bookable storefront, guest portal and payment links cover most needs out of the box. Reach for the API when you want something the storefront cannot do — your own booking front-end, a kiosk, or wiring bookings into systems you already run.

Good reasons to reach for the API

  • An existing website
    Keep your own booking journey and let RideLoop hold the fleet behind it.
  • Your own reporting
    Pull bookings and payments into the warehouse you already run.
  • A hotel or park system
    Let a front desk book bikes without leaving the system they live in.
  • Kiosks
    Drive a self-service booking terminal of your own.

Start free, and generate a key once you’re on a plan that includes it.

API access is real on Growth and Enterprise. Sign up free today, and upgrade the moment you’re ready to build.

Read the docs