Bookings & sessions

Create a complete booking or compose changes around an existing session. A booking can contain several sessions; actions on one session must preserve its siblings.

Admission inputs and results

Native booking admission accepts email and explicit sessions[]. Supply service, concrete setup, local date/start, sold duration and every applicable quote requirement: guests, recording seats, add-ons, file transfer, forms, invoice details and actual consent acceptance.

The write needs a persisted UUID and current session/client/payment authority, including conditional client creation authority. HTTP 202 returns real identities where applicable. Follow resource_type and resource_id to the current checkout or other returned resource. Availability/quote reads create no hold; admission rechecks current policy.

For studio-collected money, ordinary admission uses external checkouts with the same complete selection. Existing package rights instead use the owned-client rights/quote/redemption operations; a plan ID alone is not a usable right.

Published Tours

Use the published Tour offer, its availability and Tour quote, then Tour booking with the Tour ID in the path. Preserve setup-bound versus studio-wide roomless geometry. Tour guests use first name, last name and email; Tour consent is terms only. If phone is required, update the owned client profile first.

Tour payment_source defaults to native; external uses studio collection and its authority/readiness prerequisites. A positive external total returns a real external payable. A zero-total Tour uses its native no-Payment policy; do not fabricate a payable. Follow the returned resource type.

Move a session in time

Customer reschedule changes local date and start time while retaining sold duration. Ordinary sessions keep their booked setup even if setup_id is supplied. That optional setup selection applies only to studio-tour sessions.

The explicit staff reschedule has separate authority/policy; do not automatically retry a customer refusal through the staff route. A time move is not a commercial change to duration, setup or sold extras.

Change the sold selection with an amendment

Read amendment options, then preview the full proposal. The proposal includes the service, setup, room, date/start, duration, recording seats, add-ons, file transfer, guests and form answers required by its exact schema. Supply payment source, credit choice and displayed consents.

Accept the amendment with that proposal and the preview's expected_version, plus financial/credit choices and consents. Retain the amendment ID and read its current state. Price differences, credits, staff approval and fulfillment remain Podyx policy. A stale version requires another preview/customer decision, not a guessed replacement version.

Amendments have separate withdrawal, staff approval, decline and native payment operations. Each command has its own request UUID. An accepted proposal is not proof the changed session is fulfilled; inspect payment, approval and current session facts.

Manage guests and paid add-ons

List session guests, then use the dedicated invite, update or remove operation. Ordinary aftercare guest input uses name and its optional contact fields; do not reuse Tour guest input. Capacity and current session eligibility still apply. Invitation processing is not proof of email delivery.

Quote add-on purchases against the relevant selection and use session add-on purchase with chosen quantities, payment source, credit choice and consents. Read the add-on purchase resource and its actual payment/approval state. Native preparation/token/confirmation/retry and staff decision operations are separate. Paid extras keep their own tender and original booking payment pointers; do not overwrite them with an amendment payment.

Cancel with the right scope

Preview cancellation on the booking, supplying slot_id for one session. Submit the returned fingerprint as expected_fingerprint to accept cancellation, retaining the same scope. Omitting session scope can affect the booking more broadly; do not omit it when the customer chose one session.

Read the cancellation for its frozen plan, collection sources and required actions. A live sibling retains its own extras/aftercare eligibility. Cancellation or staff decline can create a refund obligation without executing the refund.

Recovery and current state

Persist each command UUID and exact facts before sending. A timeout after any change is uncertain: replay the original command, then read the returned resource. Do not create another amendment, add-on purchase or cancellation to discover the first result. Inspect booking/session, payment and approval facts separately.