Public API — Overview & Limitations

This is an experimental feature.

This article covers our new Public API — what it does today andits current limitations. It's aimed at technical/development teams looking to integrate their own systems with Bike Reservation Manager.

What is the Public API?

The Public API lets your own systems read and update your Bike Reservation Manager reservation data directly, server-to-server — for example, to power your own customer-facing post-booking page, sync bookings into another system, or automate check-in/check-out from your own tools.

Before you integrate: only bookings made after your store's booking-reference format switch are visible through the API. That switch is one-way and is not retroactive — every booking made before it happened stays permanently unreadable via the API, even after the switch. If you're not sure whether your store has switched yet, check with support before assuming your full booking history will be available.

Current availability

The Public API is in early access. It is not yet generally available to all stores — we're onboarding a small number of integration partners first while we harden the platform and gather real-world feedback.

If you're interested in building on the API, please get in touch with your account manager or raise a ticket with our support team to get it enabled for your store. Once it's enabled, generating and managing API keys is entirely self-serve — see Authentication below.

What you can do today

• Read a reservation by its booking reference — dates, stage/status, customer contact details, payment state (total, received, balance, deposit), and booked items.
• Update a reservation(the key used must have write access — see Authentication below):
  • Update the customer's contact details
  • Add a staff-visible note to the booking
  • Record check-out (rental start) and check-in (rental return)
  • Request a cancellation (a store staff member still makes the final call)

Write requests must include an Idempotency-Key header (a unique value you generate per request) — a write request sent without one is rejected with a 400.

The full technical reference — every field and endpoint, kept in sync with the live API — is published per region; see Regions below.

Authentication

API keys are issued to either an organisation or a single store — most stores aren't part of an organisation, so for most integrators this will be a store-level key, not an organisation-wide one.

• Key management is self-serve: users with Admin or API Admin permission can see the Public API Keys setting and create, rotate, or revoke keys themselves, with no need to contact support. (Ops involvement is limited to enabling the Public API for your store in the first place — see Current availability above.)
• When creating a key, the API Admin chooses whether it has read and/or write access — there's no separate approval step or opt-in required for write access.
• You can have up to 5 keys per organisation or store.
• Keys can be locked to specific IP ranges, so you can restrict a key to only work from your own servers.
• Keys are a server-side secret — they must never be used in browser or mobile app code. The API deliberately does not support cross-origin (browser) requests.
• If a key is compromised, rotate or revoke it yourself from the Public API Keys setting — no need to contact support. Rotating a key gives a 7-day overlap window where both the old and new key work, by design, so you can update your integration with no downtime.
• 
  

Regions

The API is region-local, matching where your store's data lives:

• EU — API: https://api.bikerentalmanager.com · Docs: api.bikerentalmanager.com/docs
• US — API: https://api-us.bikerentalmanager.com · Docs: api-us.bikerentalmanager.com/docs
  
  

Current limitations

As an early-access product, there are some deliberate constraints today:

• Only bookings made after your store's booking-reference format switch are available — see the note near the top of this article. This is the constraint most likely to catch integrators out, so check it before you build.
• Reservations only — there's no inventory or availability endpoint yet.
• Rate limit — requests are limited per organisation (currently 120 requests/minute, shared across all of your organisation's keys). This limit is subject to change as the API matures; your response headers always show your current limit and how much you have left.
• No sandbox/test keys yet — there is currently no dummy-data environment to test against; integrations are built and tested against real store data.
• No request-level history — the Public API Keys page shows a usage panel with per-key call counts for this month and last month, but not a log of individual requests. Contact support if you need to trace a specific request (see Getting help below).
  
  

Getting help

Questions about access, a specific request, or something you'd like the API to support? Contact support and quote any X-Request-Id header from the request in question so we can find it in our logs quickly.