Changelog

The wire version is the API contract's version (info.version in the OpenAPI document). The SDK version is the TypeScript package that implements it. Within a wire version every change is additive.

2026-10-13 · wire 0.2.0-preview.2 · SDK 0.2.0-preview.6

The first partner release: the developer site, the sandbox and this SDK. (SDK 0.2.0-preview.5 was not released to partners; its changes are below.)

Reservation requests

• New operations reservation.reservationRequest.create (POST /v1/reservation-requests) and reservation.reservationRequest.get (GET /v1/reservation-requests/{reservationRequestId}): a partner-settled application requests a reservation from an accepted quote and its guest in one call, and reads its outcome (pending, unresolved, confirmed or failed, with failure.reason when known) with its access token. The checkout operations are unchanged.
• Reservation requests take an optional partnerReference, unique among your application's requests, and return it. New operation reservation.reservationRequest.list (GET /v1/reservation-requests) lists your requests newest first, or finds one by partnerReference.
• A quote backs one reservation: reservation.reservationRequest.create on a quote another of your requests or checkouts already uses answers 409 conflict, whatever its reservationRequestId. To try again after a failed request, quote again.
• Every 202 Accepted answers with Location, the resource to read for the outcome, and with Retry-After while there is something to wait for (the response's pollAfterSeconds).

Reservations, references and events

• A new reservation's reference is Brightwild's, such as BW-4F7K-9QXM, wherever it appears: the confirmation, reservation.reservation.get, reservation requests and webhooks. A reservation made earlier keeps its reference, which still resolves.
• New operation reservation.reservation.get (GET /v1/reservations/{reference}): a reservation your application made, as Brightwild holds it now, including changes by Brightwild's reservations team.
• Webhooks: signed per Standard Webhooks, for your own checkouts and reservations. checkout.resolved when a submitted checkout reaches its final state, and reservation.confirmed, reservation.cancelled and reservation.changed (dates, party, price or home) whoever makes the change. Events carry identifiers, state, version and time, with a schemaVersion; endpoints and signing secrets are managed in a webhook portal. Delivery starts when Brightwild enables your application's portal; every event is recorded from now, and the event feed serves it either way. See the guide's Webhooks section.
• New operation reservation.event.list (GET /v1/events): your application's webhook events, oldest first, for the last 30 days, whether or not they were delivered, with a cursor that holds its place at the end. A cursor older than the window answers 422 resync_required.
• Checkouts and their status carry failure.reason (sold_out, quote_expired, price_changed, policy_changed, authority_revoked or refused) when a submitted checkout ends failed or expired for a known reason. The field is new and optional.

Reads, errors and latency

• Search and calendar results may be up to about a minute or two old: the API answers identical requests from a short-lived cache, and meta.asOf says when a result was read. Quotes are always live and are the price.
• A live search or calendar read that takes longer than about five seconds answers 503 unavailable (retryable) instead of holding the request open.
• reservation.quote.create answers a retryable 503 unavailable, instead of 500 internal, when the provider prices the stay with a quote that has already expired.

Developer site, sandbox and SDK

• Published the partner guide, the API reference and this changelog on the developer site.
• The OpenAPI document lists the production (https://api.brightwild.com) and sandbox (https://sandbox.api.brightwild.com) base URLs as servers. No operation changed.
• The sandbox (https://sandbox.api.brightwild.com) serves this contract with simulated listings, photos, prices, booked dates and outcomes, and its own token endpoint for sandbox keys. A guest email suffix chooses an outcome: +sold_out, +price_changed, +policy_changed, +authority_revoked and +quote_expired end a checkout with that reason; +uncertain_confirmed and +uncertain_failed resolve an uncertain checkout about 5 seconds later; +cancelled and +changed confirm a reservation, then cancel it or move its dates. Sandbox webhook delivery follows. The sandbox and the SDK's simulator serve every operation above, with references in the same format.
• SDK: the webhook event schemas and types (partnerWebhookEventSchema, PartnerWebhookEvent); the simulator's webhooks option emits the same events in process, and cancelReservation() and changeReservation() act as Brightwild's reservations team. Two runnable starters: starter/journey.mjs (checkout with simulated payment) and starter/partner-journey.mjs (a partner-settled reservation request).
• SDK simulator: six fictional listings in place of one, with the API's quotas, party rules and check order; partner-settled and card-paying application profiles; tokens with the API's claims; settle() now returns a promise, so await it.

2026-10-06 · wire 0.2.0-preview.2 · SDK 0.2.0-preview.4

• Applications authenticate with an application ID and key, exchanged at POST /oauth/token (OAuth 2.0 client_credentials) for an access token of at most 15 minutes. Every /v1 call sends the token as a bearer token.

2026-10-05 · wire 0.2.0-preview.2

The current contract:

• Operations are named <domain>.<entity>.<verb>; a response is the operation's output, and errors share one envelope with a request ID.
• Listings are addressed by listingId under /v1/listings.
• Creates take client-supplied IDs (quoteId, checkoutId, signalId), or an Idempotency-Key, so retries return the same resource.
• Every checkout carries a version; checkout commands name the version they read (expectedVersion or If-Match), and a stale version answers 412 precondition_failed.
• Payment setup and submit are asynchronous (202 Accepted); a submitted request is durable, so recovery is reading the checkout.