Keynetic

Changelog and versioning

What changed, newest first. Dates are when it went live.

What we promise not to break

  • Fields are added, never removed or retyped, inside /api/v1/. Parse leniently and ignore what you do not know.
  • Error code values and OTA @Code values are stable. Branch on those, never on the message text.
  • A breaking change gets a new path, and the old one keeps working for at least six months with notice by email to every key holder.
  • Amounts are always integer cents with an explicit currency. There is no float anywhere in the API.

Published developer surface

  • OpenAPI 3.1 description at /api/v1/partner/openapi.json, importable into Postman, Insomnia or a generator.
  • The XML gateway has its own page with the message table, the error codes we emit, sample payloads and the certification checklist we run.
  • A public sandbox workspace: two stations, four classes, a one-car class and a station that refuses one-way, so every branch can be tested before a key exists.
  • Rate limits are now stated and enforced: 240 requests per minute per key, shared between the JSON API and the XML gateway, answering 429 with Retry-After.

Availability per station, booking changes, itemised charges

  • Availability is counted at the pickup station rather than across the whole fleet, at minute precision, with the turnaround buffer between rentals and the one-way flow between stations. Operators switch it on per workspace.
  • PATCH /bookings/{reference} changes a confirmed booking and reprices it, with ?preview=1 to price without saving. On the XML side, OTA_VehModifyRQ with the full ModifyType and CancelType handling.
  • Every quote, booking and change returns the full charge breakdown: base rate with its periods, cover with the excess, equipment with any day cap, mandatory fees and per line tax.
  • Cars in maintenance or out of service are never sold and rejoin supply on their back-in-service date. Overdue rentals hold their car; a missed pickup releases it.
  • Creating a booking is idempotent on partner_reference: a retry returns the original booking with replayed true.
  • Bookings are scoped to the key that made them, so one partner can never read or change another partner’s booking at the same operator.

Want to hear about changes before they ship? Email [email protected] and we will put your integration team on the list.