Changelog

This page tracks changes to the public /v1 API.

Additive only

Within a version, changes are additive only — new fields, new endpoints, never a renamed or removed one. A breaking change means a new version (/v2), not a change to /v1.

Unreleased

Live today:

• GET /v1/ping — liveness check.
• GET /v1/availability — resource availability by date range and party size.
• GET /v1/resources, GET /v1/resources/{id} — resource, room-type, and rate-plan read.
• GET/PUT /v1/resources/{id}/rates, GET/PUT /v1/resources/{id}/restrictions — rate and restriction management.
• POST /v1/rates/bulk — set a nightly rate and/or a restriction across a date range for many resources of the same room type in one call (sk_ only).
• GET /v1/metrics/summary — revenue and occupancy for a date range, defaulting to the current calendar month (sk_ and an operator session only — it’s money, so pk_ can never call it). Powers the dashboard’s Today screen.
• GET /v1/resources/{id}/calendar — per-day availability, price hint, and restrictions over a date range. See Calendar and iCal feeds.
• GET /v1/feeds/{token}.ics and the feed-token endpoints (/v1/resources/{id}/feed-tokens) — iCal export of confirmed bookings and synced external blocks. See Calendar and iCal feeds.
• iCal import — pulling an already-connected OTA’s calendar in as external blocks — runs automatically once your operator contact sets up the connection.
• POST /v1/quotes — priced, signed, 15-minute quotes.
• POST /v1/holds/{id}/otp, POST /v1/holds/{id}/otp/verify — guest email verification.
• POST /v1/holds, POST /v1/holds/{id}/confirm — hold creation and confirmation. Confirming a hold requires a succeeded card payment — see Holds and confirmation.
• POST /v1/holds/{id}/payment-intent — creates a Stripe PaymentIntent for a held reservation, for a server-side integration using Stripe.js or Stripe Elements directly (sk_ only).
• POST /v1/holds/{id}/checkout-session — creates a Stripe-hosted Checkout Session for a held reservation and returns a redirect URL (sk_ and pk_); this is what the embeddable widget uses to take payment.
• Card payment (Stripe) is live: both the server-side PaymentIntent flow and the widget’s hosted-checkout flow confirm a reservation automatically once Stripe reports a succeeded payment.
• GET/PATCH/DELETE /v1/bookings/{id} — booking read, transition, and cancellation (sk_ only).
• POST /v1/bookings/{id}/refunds — full or partial refund of a booking’s succeeded payment (sk_ with payment:refund:create, or an operator session — never pk_, the same “no money” rule as everywhere else). See Refund a booking.
• The embeddable widget — a full booking flow: availability, quote, hold, and payment through a Stripe-hosted checkout page. See Embed the widget. A live demo runs at /widget-demo/.
• The embeddable availability calendar — a separate, smaller, read-only widget: availability and a per-night price hint for one resource, no booking flow, pk_-authed, no PII. See Embed the calendar. A live demo runs at /calendar-demo/.
• The dashboard’s Today screen now leads with a revenue, occupancy, and bookings-this-month summary, alongside Payments, API Keys, the widget configurator (which now generates both the booking widget’s snippet and the calendar embed’s), and Settings — all live for operators.

Not yet released

Outbound webhooks (to your own endpoints — the inbound Stripe webhook is live), direct OTA connectivity beyond iCal (for example a Booking.com Connectivity integration), the generated SDK’s public registry publish, and a resource/rate-plan picker inside the widget.

This changelog starts recording dated entries once the API reaches its first tagged release.