@wix/agent-skills 1.35.1 → 1.36.1

package/skills/wix-headless/references/inline-recipes/how-to-code-pricing-plans.md

@@ -1,126 +0,0 @@
----
-name: "How to Code Pricing Plans"
-description: The frontend contract for a Wix Pricing Plans (Plans V3) site — which `@wix/pricing-plans` modules to import, how to list plans for the grid, order a plan for a logged-in member, read the member's own subscriptions, and (the integration) let a member book a Bookings service with their membership. Specifies the *how* (modules + exact calls + the failure modes the docs omit); which plans to render and how the page looks come from the request.
----
-**RECIPE**: How to Code a Wix Pricing Plans Frontend (Plans V3 + members + the Bookings-membership integration)
-
-A contract for the **frontend code** of a pricing-plans site: showing the plans grid, subscribing (ordering) a plan, a member's "my subscription" surface, and — when the site also has Bookings — booking a service **with** an active membership. **This recipe is the *how* (which modules, which calls, which fields), not the *what*** — which plans to show, how the page looks, and the framework come from the request you're fulfilling.
-
-> **This recipe is for CODING, not seeding.** It assumes a Plans V3 backend already exists (plans created, and — for the integration — bookings services attached to a plan via Benefit Programs; see `setup-pricing-plans.md`). It says nothing about creating plans — only how to read and buy them from frontend code.
-
-> **⚠️ Reading rule — append `.md?apiView=SDK` to every doc link below.** Wix docs render two views: the **bare/REST view shows `id`**, the **`?apiView=SDK` view shows `_id`** — the SDK is what your frontend calls. A surprising field name usually means you're reading the REST view. Discover any shape not pinned here with `SearchWixSDKDocumentation`, not by guessing a URL.
-
-> **⚠️ pricing-plans is a HARD dependency on members.** Ordering a plan and the "my subscription" surface both require a **logged-in member** (browsing the grid is public). So this recipe is always paired with member auth — read the matching **`how-to-code-members-astro.md`** or **`how-to-code-members-non-astro.md`** for the login flow. A logged-in member ordering their own plan needs **no `auth.elevate`** and **no `onBehalf`**.
-
----
-
-## The modules and the client (read this first)
-
-**⚠️ Two different packages — use the headless one.** The Wix docs surface `checkout.startOnlinePurchase()` / `checkout.createOnlineOrder()` under **`@wix/site-pricing-plans`** — that is the **Wix-site (Velo / `$w` page-code) package**, and `startOnlinePurchase` drives the **Wix Pay frontend UI** that only exists inside a hosted Wix page. **It is NOT the headless path** — do not import `@wix/site-pricing-plans` in a headless frontend. Use **`@wix/pricing-plans`** (the universal/headless SDK), whose `orders.createOnlineOrder` creates the order and leaves payment to a redirect you drive (see *Subscribing*).
-
-| Need | Package | Module / namespace |
-|---|---|---|
-| List / read plans (the grid) | `@wix/pricing-plans` | `plansV3` (Plans V3 — `queryPlans`, `getPlan`) |
-| Order a plan + read a member's orders | `@wix/pricing-plans` | `orders` (`createOnlineOrder`, `memberListOrders`, `memberGetOrder`) |
-| Member login / current member | `@wix/members` + `@wix/sdk` auth | see the members recipe (`getCurrentMember`, `loggedIn()`) |
-| Book a service with a membership (integration) | `@wix/bookings` + `@wix/ecom` (+ `@wix/redirects`) | `bookings` (`createBooking`), ecom `currentCartV2` (line-item `membershipPayment`) — see *Booking with a membership* |
-
-> Migrating from Cart V1 / Checkout V1? The code below is V2-only — see the [migration guide](https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/purchase-flow/cart-v2/migration-guide) for the before/after.
-
-**Never** import `@wix/site-pricing-plans` in headless code, and don't reach for a V1 `plans`-collection query — Plans V3 (`queryPlans` → `pricingVariants`) is the shape the seed creates.
-
-> **⚠️ The read module is `plansV3`, not `plans`.** In the `@wix/pricing-plans` SDK, `queryPlans`/`getPlan` live on the **`plansV3`** namespace (`import { plansV3, orders } from '@wix/pricing-plans'`). Importing `plans` and calling `plans.queryPlans()` fails to type-check (`Property 'queryPlans' does not exist`). `orders` keeps its own namespace.
-
-**Auth / client — framework split** (same split as every other coding recipe):
-- **Astro (Wix-managed):** auth is ambient — call `plansV3` / `orders` directly from server components / `src/pages/api/*`. Member identity rides on the call automatically after login (`how-to-code-members-astro.md`). **No `createClient`, no `OAuthStrategy`, no `clientId`.** A member reading their own orders needs **no `auth.elevate`**.
-- **Non-Astro (Vite/React/Vue/static):** build one manual client and reuse it — the **same** `OAuthStrategy` client the members/visitor flow already builds (don't make a second one). After the member-login handshake sets member tokens on it, `orders.*` runs as that member:
-  ```js
-  import { createClient, OAuthStrategy } from '@wix/sdk';
-  import { plansV3, orders } from '@wix/pricing-plans';
-  const client = createClient({ modules: { plansV3, orders }, auth: OAuthStrategy({ clientId: /* public OAuth id */ }) });
-  ```
-
-> **The connected site must be PUBLISHED** — the Pricing Plans APIs return nothing / error against an unpublished site and don't work in preview (same precondition as member login). Publish before testing.
-
----
-
-## The features (build the ones the site needs)
-
-Each subsection is self-contained — build only what the site uses.
-
-### Listing plans for the grid (public, and the `_id` rule)
-
-```js
-const { items } = await plansV3.queryPlans()
-  .eq('visibility', 'PUBLIC')
-  .find();                                    // items[] of Plan
-```
-Doc: <https://dev.wix.com/docs/api-reference/business-solutions/pricing-plans/plans-v3/query-plans.md?apiView=SDK>
-
-- **The grid read is public** — a visitor token lists `PUBLIC` plans; no login needed just to browse.
-- **⚠️ Entity id is `_id`, not `id`** — `plan._id` is what you order by and key React lists on. (`plan.id` is `undefined` in SDK code — you're reading the REST view if you see `id`.)
-- **⚠️ Price lives in `pricingVariants[]`, NOT a top-level `price`.** Read the amount from `plan.pricingVariants[0].pricingStrategies[0].flatRate.amount` (a **decimal string** — parse before math) and the cycle from `plan.pricingVariants[0].billingTerms.billingCycle` (`{ period: "MONTH", count: "1" }`). A free plan has no `flatRate` amount; a one-time plan has different `billingTerms` (see the seed recipe). `plan.currency` is the site's currency — format from it, don't assume USD.
-- **Show only `buyable` plans with a buy button.** `visibility: "PUBLIC"` can still be `buyable: false` (assign-only) — render those without a subscribe action, or filter them out.
-- **Perks** for the plan card are `plan.perks[]` (each `{ _id, description }`) — display-only text. (`queryPlans` returns them; if a summary trims them, `plansV3.getPlan(planId)` returns the full object.)
-
-### Subscribing (ordering) a plan — login-gated
-
-Ordering is a **member** action. Gate the subscribe button on `client.auth.loggedIn()` (non-Astro) / a resolved member (Astro) and bounce anonymous users into the login flow first (members recipe). Then:
-
-```js
-const { order } = await orders.createOnlineOrder(planId);   // planId = plan._id; logged-in member ⇒ no onBehalf
-// order.status: "DRAFT" (payment not yet made) | "ACTIVE" (free plan — already applied)
-```
-Doc: <https://dev.wix.com/docs/api-reference/business-solutions/pricing-plans/orders/create-online-order.md?apiView=SDK>
-
-- **⚠️ A logged-in member needs no `onBehalf`** — the order is created on their behalf from the member identity. `onBehalf.memberId` is only for an app/admin identity ordering *for* someone (and needs elevation) — don't reach for it in a normal member flow.
-- **⚠️ `DRAFT` ≠ subscribed.** `createOnlineOrder` **orders but does not pay** — a paid plan comes back `status: "DRAFT"` and is not active until payment completes. Do not show "you're subscribed" off the `createOnlineOrder` return for a paid plan.
-- **Free plan:** returns `status: "ACTIVE"` (`lastPaymentStatus: "NOT_APPLICABLE"`) directly — no payment step; render success immediately. **Branch on the plan being free** (no `flatRate` amount / total `0`) to skip the redirect below.
-- **⚠️ Paid plan — the payment redirect handoff is the one piece not pinned by the docs for headless.** The all-in-one `startOnlinePurchase` that completes payment is the **site-package** method (above), unavailable headless; the headless `createOnlineOrder` returns a `DRAFT` order carrying a `wixPayOrderId`, and the member must be sent to a hosted payment flow to complete it. **⚠️ VERIFY IN A LIVE BUILD:** confirm the exact headless redirect — whether you pass the order to `@wix/redirects` `createRedirectSession({ paymentCheckout: { … } })`, or a pricing-plans-specific redirect — before shipping the paid path. Do not assert a specific call here until a real build confirms it. (The `origin`/`postFlowUrl` allowlist + `https`-host rules from `how-to-code-a-store.md`/`how-to-code-bookings.md` apply to whatever redirect is used.) The **free-plan** path above is fully client-only and needs no redirect.
-- **⚠️ SCOPE — the frontend's job ends at `createOnlineOrder` + the payment redirect. STOP THERE.** Do **NOT** try to *complete or activate* the purchase from code: don't connect a payments provider (`payments/v1/wix-payments-account/connect`), don't `PATCH`/update-plan to force a state, don't call mark-as-paid, and don't hunt for an "admin way to activate the order" or to "enable payments for a $0 order." Payment completing (a paid order flipping `DRAFT → ACTIVE`) happens **out-of-band** on Wix's hosted flow / by the merchant configuring payments — it is **not** a frontend step, and chasing it is a rabbit hole (it burns the run and ships nothing extra). A **free** plan already returns `ACTIVE` with no payment; a **paid** plan is `DRAFT` until the member pays through the redirect. If the site has **no payment provider configured**, that's a **site-setup precondition** (like the events paid-ticket precondition) — surface it, don't try to fix it in code.
-
-### The member's "my subscription" surface — login-gated
-
-```js
-// the logged-in member's own orders:
-const res = await orders.memberListOrders();       // filtered: orders.memberListOrders({ planIds, orderStatuses, paymentStatuses, limit, offset })
-// ⚠️ member-scoped reads are memberListOrders / memberGetOrder — there is NO `orders.listOrders`/`getOrder` (those are the admin `managementListOrders`/`managementGetOrder`, server/elevate only).
-// ⚠️ filter args are TOP-LEVEL limit/offset, NOT a nested `paging` object.
-// each order: { _id, planId, subscriptionId, status, lastPaymentStatus, startDate, endDate, currentCycle, planName, pricing, planPrice }
-```
-Doc: <https://dev.wix.com/docs/api-reference/business-solutions/pricing-plans/orders/introduction.md?apiView=SDK>
-
-- **⚠️ Login required — returns nothing for an anonymous visitor.** Gate this surface behind auth; don't render "my subscription" for a logged-out user.
-- **"Currently active" = `status === "ACTIVE"` AND now is within `startDate`…`endDate`.** A `CANCELED` order can still be within its paid period until `endDate`; `autoRenewCanceled: true` means it won't renew but may still be active now. Don't treat `CANCELED` as "no access" without checking the date window.
-- Same **no-`auth.elevate`** rule: a member reading their own orders is authorized under the member token. Listing *all* members' orders is the admin/elevate axis (server-only) — not this.
-
-### Booking a service with a membership (the integration — only when the site also has Bookings)
-
-This is the payoff of the seed's STEP 2: a member who holds a plan that **covers** a service books it **with the membership** instead of paying per booking. Build the normal Bookings flow from **`how-to-code-bookings.md`** (list services → pick a slot → collect the form → `createBooking` → ecom cart/checkout); the membership is a **delta on that flow**, not a separate path:
-
-1. **Require login** — membership payment resolves against the member identity (a covered service booked anonymously just falls back to pay-per-booking).
-2. **On `createBooking`, set `selectedPaymentOption: "MEMBERSHIP"`** (instead of `ONLINE`/`OFFLINE`). Enum values: `ONLINE`, `OFFLINE`, **`MEMBERSHIP`** (pay with a pricing plan), `MEMBERSHIP_OFFLINE`. Doc: <https://dev.wix.com/docs/api-reference/business-solutions/bookings/bookings/bookings-writer-v2/create-booking.md?apiView=SDK>
-3. **The booking still rides the ecom cart** (Bookings is an ecom catalog, appId `13d21c63-b5ec-5912-8397-c3a5ddb27a97`) — the membership is applied **on the cart line item**, not on the booking object. Set membership selection on the line item via `updateLineItemsInCurrentCart`:
-   - **Apply one** by setting the line item's `membershipPayment` via `currentCartV2.updateLineItemsInCurrentCart({ lineItems: [{ lineItemId: <booking line item id>, membershipPayment: { existingMembership: { membershipId, appId } } }] })` — `membershipId`/`appId` identify the member's existing plan membership (the Pricing Plans app); the line item reads it back as `paymentConfig.membership`. When the membership covers the full price, the calculated total drops to `0`.
-   - **Which plan to apply / eligibility:** the cart has **no** candidate-memberships read in V2 — `calculateCurrentCart` → `summary.paymentSummary.memberships` lists memberships **already applied**, not candidates — so which plan to apply comes from the member's plans + live coverage (see the LIVE-read note below). **⚠️ VERIFY IN A LIVE BUILD** which `appId`/`membershipId` a headless member token must pass.
-   Doc: <https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/purchase-flow/cart-v2/update-line-items.md?apiView=SDK>
-4. **⚠️ Do NOT call `confirmBooking`** — for a membership payment Wix **auto-confirms** the booking on redemption (the same "no confirmBooking" rule as `how-to-code-bookings.md`; the membership drives confirmation).
-
-- **⚠️ Eligibility / coverage is a LIVE read, never a hardcoded plan→service map.** A new eligible plan, or a service newly added to a plan's coverage in the backoffice, **must be honored with no code change** — so never freeze the seed-time `{ planId → serviceIds }` map into the frontend. Since Cart V2 has no per-line "eligible memberships" read, compute eligibility from the member's own plans against live coverage: list the member's active orders (`orders.memberListOrders`, `status: ACTIVE` within the date window) and match each `planId` against the plan's **live** Benefit-Program coverage (query the program's items — the same API `setup-pricing-plans.md` STEP 2 wrote to — at request time; do **not** read a coverage map baked into code). Set `selectedPaymentOption: "MEMBERSHIP"` on the booking + the line item's `membershipPayment.existingMembership` from the matched plan.
-- **⚠️ A `MEMBERSHIP` booking on a service the plan does NOT cover fails at checkout** (unless `skipSelectedPaymentOptionValidation`, which needs elevation — don't use in a member flow). Only offer "book with membership" for services actually covered by one of the member's active plans; otherwise fall back to the normal paid booking (`how-to-code-bookings.md`).
-- **Credit/session plans:** for a limited (non-unlimited) plan, don't pre-read a balance — apply the membership, then `calculateCurrentCart`/`estimateCurrentCart`. The summary lists the applied memberships (`summary.paymentSummary.memberships`), the covered line's `paymentConfig.membership` carries `redemptionCost` (balance deducted for this booking; `0` = unlimited) + `redemptionType` (`CREDITS`/`SESSIONS`), and an exhausted/over-limit plan surfaces **explicitly** as a `summary.violations` entry (or an error at place-order) — treat that as "not eligible." The ecom cart itself carries no remaining-balance read; the balance is owned by the plan's **Benefit-Program** domain (the same source as the coverage check above), so if you need the actual number read it there — not off the cart. An unlimited plan (seed `price:"0"`) has no ceiling.
-
-### Out of scope (do not build these)
-- **Completing/activating payment from code** — connecting a payments account, marking orders paid, forcing an order `ACTIVE`, "activating" a subscription server-side. Payment is the member's hosted-flow step or a merchant dashboard/config task, never frontend code (see the SCOPE callout under *Subscribing*).
-- **Configuring which services a plan covers** — that coverage is wired at seed time via Benefit Programs (`setup-pricing-plans.md` STEP 2); the frontend only *reads/uses* it, it doesn't create or edit it.
-- **Cancelling / pausing / refunding a subscription, and dunning/renewal management** — post-purchase lifecycle beyond a read-only "my subscription" view is the hosted member area / dashboard, not this build.
-- **Offline orders** (`createOfflineOrder` / mark-as-paid) — a merchant/admin flow, not a member-facing frontend one.
-
----
-
-## Conclusion
-A correct Pricing Plans frontend:
-- imports **`@wix/pricing-plans`** (`plansV3`, `orders`) — **never** `@wix/site-pricing-plans` (its `startOnlinePurchase` is Wix-site page-code, not headless);
-- lists the grid publicly with **`plansV3.queryPlans().eq('visibility','PUBLIC')`**, reads **`plan._id`** and price from **`pricingVariants[].pricingStrategies[].flatRate.amount`** (decimal string) — never a top-level `price` — and only shows a buy button on `buyable` plans;
-- treats **subscribe and my-subscription as login-gated** (the hard members dependency), orders with **`orders.createOnlineOrder(planId)`** (no `onBehalf`, no elevate), renders free plans as `ACTIVE` immediately, and drives paid plans through a payment redirect (**exact headless redirect to be confirmed in a live build**) — and **stops at the redirect**: no payments-account connect, no order activation / mark-as-paid from code (see *Out of scope*);
-- for the Bookings integration, books a covered service by setting **`selectedPaymentOption: "MEMBERSHIP"`** on `createBooking`, applies the membership on the **ecom cart line item** (`membershipPayment.existingMembership` via `updateLineItemsInCurrentCart`), never calls `confirmBooking`, and falls back to matching the member's active-order `planId`s to the service's coverage when the cart eligibility field isn't readable client-side.

package/skills/wix-headless/references/inline-recipes/how-to-code-rentals.md

@@ -1,254 +0,0 @@
----
-name: "How to Code Rentals"
-description: The frontend read/booking contract for a Wix Rentals site — a delta on how-to-code-bookings.md. Covers filtering the catalog to rentals, the two-call hourly availability flow (start slots then end options), the consecutive-day walk for daily rentals, duration-based price preview, and the createBooking → ecom Cart V2 → checkout-or-place sequence with the rentals app id. Specifies the *how* (modules + exact calls + rentals-specific failure modes); which rentals to render and how the page looks come from the request.
----
-**RECIPE**: How to Code a Wix Rentals Frontend (Services V2 duration ranges + ecom Cart V2 checkout)
-
-> **⚠️ Read `how-to-code-bookings.md` first — this recipe is a DELTA on it, not a replacement.** Wix Rentals runs on the Wix Bookings APIs, so the client setup, the schema-driven booking form, the `createBooking → ecom Cart V2 → checkout-or-place` sequence, and the `postFlowUrl` HTTPS trap are **all identical** and are documented there. This file covers **only what differs for a rental**: finding rentals, duration-range availability, duration-based pricing, and the handful of rentals-specific errors.
-
-> **⚠️ There is no `@wix/rentals` package, and that is not a gap.** Rentals is `@wix/bookings` with rentals-specific field values. If a run concludes "Wix Rentals has no headless surface" because npm has no `@wix/rentals`, that conclusion is wrong — build on `@wix/bookings`.
->
-> **Rentals doc set** (four pages, where to go beyond this recipe): [About Wix Rentals](https://dev.wix.com/docs/api-reference/business-solutions/rentals/introduction.md) · [Rentals and the Bookings APIs](https://dev.wix.com/docs/api-reference/business-solutions/rentals/wix-rentals-and-the-bookings-apis.md) (concept → API map) · [About Rentals Availability](https://dev.wix.com/docs/api-reference/business-solutions/rentals/about-wix-rentals-availability.md) · [Sample Flows](https://dev.wix.com/docs/api-reference/business-solutions/rentals/sample-flows.md) (the booking sequences below, end to end).
-
-> **⚠️ Reading rule — always append `.md?apiView=SDK` to every doc link below.** The bare/REST view shows `id`; the SDK view shows `_id`, and the SDK is what your frontend calls.
-
----
-
-## Constants and modules (the delta)
-
-**Constants** (e.g. `src/services/constants.ts`):
-- **Wix Rentals app id** — `ff5d6eb1-65e4-4f9a-8b14-64d34c12cc2e`. Used **three times**: to filter the catalog to rentals, as the cart's `catalogReference.appId`, and to filter bookings reads (§Cancellation).
-
-**Modules** — all on `@wix/bookings`, alongside the ones `how-to-code-bookings.md` already lists:
-
-| Need | Package | Module |
-|---|---|---|
-| Rental catalog with availability/attribute filters | `@wix/bookings` | `catalogSearch` (`queryServicesByFilters`) |
-| Start times for a rental | `@wix/bookings` | `availabilityTimeSlots` (`listAvailabilityTimeSlots`) |
-| End times for an **hourly** rental | `@wix/bookings` | `availabilityTimeSlots` (`listAvailabilityTimeSlotEndOptions`) |
-| Duration-based price before booking | `@wix/bookings` | `pricing` (`previewPrice`) |
-| Create the booking / cart / redirect | *(unchanged)* | see `how-to-code-bookings.md` |
-
----
-
-## 1 · Find the rentals
-
-**⚠️ CRITICAL: always filter by the rentals app id.** Rentals share every API with Bookings. On a site that has both, an unfiltered `queryServices` returns haircuts next to meeting rooms. Every catalog read must carry `appId = ff5d6eb1-65e4-4f9a-8b14-64d34c12cc2e`.
-
-`catalogSearch.queryServicesByFilters` is the right entry point for a rental catalog: it filters **and** resolves availability in one call.
-
-```js
-const { results, pagingMetadata } = await catalogSearch.queryServicesByFilters({
-  query: {
-    filter: { appId: RENTALS_APP_ID },
-    sort: [{ fieldName: 'name', order: 'ASC' }],
-    cursorPaging: { limit: 20 },
-  },
-  serviceFilters: {
-    localStartDate: '2026-09-01T00:00:00',   // omit the window entirely to skip the availability check
-    localEndDate:   '2026-09-08T00:00:00',   // exclusive — start of the day AFTER the window
-    timeZone: 'America/New_York',
-  },
-});
-```
-
-- Each entry in `results` carries the full `service` plus an **`available`** flag. With a window set and `exactMatch` left unset, a service comes back when it has **at least one** bookable slot anywhere in the window.
-- **End the window at `00:00:00` of the day *after* the range you want, not at `23:59:59`.** The end boundary is exclusive, so a 23:59:59 end silently drops the last minute of the final day. This matches the daily-booking convention in §3, where a rental's `endDate` is midnight of the day after the last rented day.
-- **To grey out rather than hide** unavailable rentals, set `serviceFilters.includeUnavailable: true` — those come back with `available: false`.
-- **Paginate** by passing `pagingMetadata.cursors.next` back **unchanged** as `query.cursorPaging.cursor`, until `next` is absent.
-- **Location and attribute filters** live in `serviceFilters` too — `locationIds`, `resourceTypes`, and `attributes`. Within one attribute, values are **match-any**; across different attributes, **match-all**.
-- With **no** date range, no availability check runs and everything returns `available: true`.
-
-Doc: <https://dev.wix.com/docs/api-reference/business-solutions/bookings/services/catalog-search/query-services-by-filters.md?apiView=SDK>
-
-**Read the range off the service** to drive the UI — it tells you which of the two flows below applies:
-
-```js
-const range = service.schedule?.availabilityConstraints?.durationRange;
-const isDaily = range?.unitType === 'DAY';
-const min = isDaily ? range.dayOptions.minDurationInDays    : range.hourOptions.minDurationInMinutes;
-const max = isDaily ? range.dayOptions.maxDurationInDays    : range.hourOptions.maxDurationInMinutes;
-```
-
----
-
-## 2 · Hourly availability — two calls, start then end
-
-A fixed-duration service has one slot list. A rental has **two steps**: the customer picks a start, then picks how long.
-
-**Step 1 — start times.**
-
-```js
-const { timeSlots } = await availabilityTimeSlots.listAvailabilityTimeSlots({
-  serviceId,
-  timeZone,
-  fromLocalDate: '2026-09-01T00:00:00',
-  toLocalDate:   '2026-09-02T00:00:00',   // exclusive — start of the next day, not 23:59
-  includeResourceTypeIds: [resourceTypeId],   // the service's primaryResourceType
-  bookable: true,
-});
-```
-
-**⚠️ Pass `includeResourceTypeIds` with the service's `primaryResourceType`, or the slots come back with no resource to book.** Each slot then carries its bookable resource in `availableResources` — carry that forward, `createBooking` needs it.
-
-**Step 2 — end times for the chosen start.**
-
-```js
-const { endOptions } = await availabilityTimeSlots.listAvailabilityTimeSlotEndOptions(
-  serviceId,                                   // ⚠️ POSITIONAL first argument, not part of the options object
-  { localStartDate: selected.localStartDate, timeZone, location: selected.location },
-);
-```
-
-- **⚠️ The response field is `endOptions`, NOT `timeSlots`.** `listAvailabilityTimeSlots` returns `timeSlots`; this call returns `endOptions`. Destructuring `timeSlots` here yields `undefined` and **no error** — the end-time picker just renders empty, which is indistinguishable from "no availability". If your length picker is mysteriously blank, check this first.
-- **`location` is REQUIRED** — pass the selected slot's own `location` straight through. Omitting it fails the call.
-- The service's **maximum duration caps the response**, so you don't need `maxLocalEndDate` — the cap defaults to `localStartDate` plus that maximum. What you actually get back also depends on availability: the options stop earlier if the resource isn't free that long, so the last end option is whichever comes first — the maximum duration, or the end of the free period.
-- Every entry shares the requested `localStartDate` and differs only in **`localEndDate`** — that is the end-time picker.
-- **`availableResources` is always empty on end options**, and `totalCapacity` is always `1`. Take the resource from **step 1**, not from here.
-- **⚠️ `END_OPTIONS_NOT_SUPPORTED`** means you called this for a **daily** or a fixed-duration service. End options are hourly-only — branch on `unitType` before calling.
-
-Docs: <https://dev.wix.com/docs/api-reference/business-solutions/bookings/time-slots/time-slots-v2/list-availability-time-slots.md?apiView=SDK> · <https://dev.wix.com/docs/api-reference/business-solutions/bookings/time-slots/time-slots-v2/list-availability-time-slot-end-options.md?apiView=SDK>
-
----
-
-## 3 · Daily availability — one call, then walk the days yourself
-
-There is **no end-options call for daily rentals.** You list days and compute the valid end dates client-side.
-
-**⚠️ `timeZone` must be the site's business timezone — see [the rentals availability docs](https://dev.wix.com/docs/api-reference/business-solutions/rentals/about-wix-rentals-availability.md#daily-availability) for why.** Don't use the visitor's browser timezone.
-
-```js
-const { timeSlots } = await availabilityTimeSlots.listAvailabilityTimeSlots({
-  serviceId, timeZone,
-  fromLocalDate, toLocalDate,
-  timeSlotsPerDay: 1,
-  includeResourceTypeIds: [resourceTypeId],
-  bookable: true,
-});
-```
-
-After the customer picks a start date, **iterate forward through the returned list and stop at the first gap, or when you hit the service's `maxDurationInDays`.** Those are the selectable end dates. A naive "start + max days" range will offer dates across a gap and then fail at booking time.
-
-**How a daily rental is stored depends on the resource's working hours — and it changes which call you make:**
-
-| Resource | Stored as | Booking call |
-|---|---|---|
-| **24/7** (no working-hours schedule) — the `setup-rentals.md` default | **one** booking spanning the whole range | `createBooking` |
-| **Has working hours** | a **linked group**, one booking per working day (2–8) | `createMultiServiceBooking` with `multiServiceBookingType: 'SEQUENTIAL_BOOKINGS'` |
-
-For the **24/7** case, set the boundaries to midnight-to-midnight: `startDate` = midnight on the first day, `endDate` = **midnight on the day after the last day**. A Monday–Wednesday inclusive rental ends at midnight on **Thursday**. **⚠️ Wix derives `allDay` itself — do not set it.**
-
-For the **working-hours** case, build one booking per day with that day's own working-period start and end (e.g. 09:00 → 18:00), and send them together. The group is created **all or nothing**: any unavailable or non-consecutive day fails the whole call.
-
-Docs: <https://dev.wix.com/docs/api-reference/business-solutions/rentals/about-wix-rentals-availability.md> · <https://dev.wix.com/docs/api-reference/business-solutions/bookings/bookings/bookings-writer-v2/create-multi-service-booking.md?apiView=SDK>
-
----
-
-## 4 · Price preview (duration-based)
-
-A rental's price depends on its length, so show the total before booking.
-
-```js
-const { priceInfo } = await pricing.previewPrice([{
-  serviceId,
-  resourceId,                       // required for appointment-based services
-  numberOfParticipants: 1,          // always 1 for a rental — see below
-  localStartDate: '2026-09-01T09:00:00',
-  localEndDate:   '2026-09-01T14:00:00',
-  timeZone,                         // required whenever the local dates are sent
-}]);
-// priceInfo.calculatedPrice
-```
-
-**⚠️ `numberOfParticipants` is required and is always `1` for a rental.** Omitting it, or sending `0`, fails with `NUMBER_OF_PARTICIPANTS_NOT_FOUND`. A rental isn't a class: one booking takes one resource, so participant count never drives the price — the duration does. The room's stated capacity ("seats 8") is a resource **attribute** for display, not a participant count. Same reasoning as `defaultCapacity: 1` on the service (`setup-rentals.md` STEP 4).
-
-**⚠️ Omitting `localStartDate` / `localEndDate` / `timeZone` does not error — it silently falls back to participant-based pricing** and returns a flat rate that ignores the duration. The customer then sees one price and is charged another. Always send all three.
-
-Hourly is prorated per minute (`minutes × base ÷ 60`); daily is `base × days`. Doc: <https://dev.wix.com/docs/api-reference/business-solutions/bookings/pricing/pricing-api/preview-price.md?apiView=SDK>
-
----
-
-## 5 · Book and check out
-
-> **⚠️ LIVE BOOKING PRECONDITION — the site needs a premium plan and a configured payment method.** On a free site the visitor flow fails at the last step: `createBooking` returns **`PREMIUM_VALIDATION_FAILED`**, and `placeOrder` returns **`SITE_NOT_ACCEPTING_PAYMENTS`**. That's site provisioning, not a frontend bug — if a booking can't complete, the setup is incomplete, not the code.
->
-> Two things make this misleading. **The same `createBooking` succeeds as an admin (`WIX_USER`)**, so it reads like a permissions or payload bug when it's neither — always test the visitor path. And **switching the service to offline / pay-in-person does not avoid it**: `placeOrder` still requires the site to be accepting payments. Record the precondition and surface it to the owner; don't try to code around it.
-
-**Identical to `how-to-code-bookings.md` § "createBooking → cart → checkout"**, with four substitutions:
-
-1. **`endDate` is the customer's chosen end**, not a duration added to the start — that is the whole point of a rental.
-2. **`resource`** comes from the **start slot's** `availableResources` (§2 step 1 / §3). There is no ANY_RESOURCE staff fallback here; rentals are resource-driven.
-3. **Map the slot's `location` to the booking's `location`** — read the id as `slot.location.id ?? slot.location._id`, and write it under `_id`.
-4. **The cart's `catalogReference.appId` is the RENTALS app id**, not the Bookings one:
-
-```js
-const cart = await createCart({
-  catalogItems: [{ quantity: 1, catalogReference: { catalogItemId: bookingId, appId: RENTALS_APP_ID } }],
-  cart: { source: { channelType: 'WEB' } },
-});
-```
-
-Everything downstream — `calculateCart`, the checkout-vs-`placeOrder` decision, `redirects.createRedirectSession` and the HTTPS `postFlowUrl` rule — is unchanged. Follow `how-to-code-bookings.md`.
-
-**⚠️ One exception: do NOT call `getAnonymousActionToken` / `bookingsGetBookingAnonymously` for a rentals booking.** `how-to-code-bookings.md`'s confirmation-page step calls these client-side as the visitor. For rentals, `getAnonymousActionToken` returns `403` (the method requires the `Manage Bookings` scope, which the visitor doesn't have) — skip that whole step. Drive the confirmation page from what you already hold from `createBooking` / `placeOrder` / the redirect return instead; don't add a call to mint or read an anonymous token.
-
----
-
-## 6 · SEO on item pages, and images
-
-**⚠️ There is no `WIX_APPS.rentals.*` and no `seoTags.ItemType.RENTAL`** — a rental detail page is a **Bookings service** item page, so it uses the **bookings** accessors:
-
-- **`wixMetadata`** from `WIX_APPS.bookings.servicePageMetadata` — referenced **directly** in the export (module scope). Route param `slug` → `identifiers.slug`.
-- **`itemType`**: `seoTags.ItemType.BOOKINGS_SERVICE`.
-
-Everything else about the three-step item-page SEO wiring (`wixMetadata` export → `loadSEOTagsServiceConfig(...)` → `<SEO.Tags>`, and running the config load in the same `Promise.all` with `.catch(() => null)`) is identical to `how-to-code-bookings.md` § "SEO on item pages".
-
-**Images** are the same trap too: `service.media.mainMedia.image` is a **string** holding a `wix:image://v1/…` URI, **not** an absolute URL. Resolve with `media.getImageUrl(...)` from `@wix/sdk` before putting it in `<img src>`, and guard items with no image.
-
-**Mount the slot picker, length picker and book action in a client-only island** (Astro) — availability is timezone- and session-specific. SSR only the catalog and detail reads, for SEO.
-
----
-
-## Rentals-specific failure modes
-
-| Error | Cause | Handling |
-|---|---|---|
-| Empty length picker, no error | Destructured `timeSlots` from end options instead of **`endOptions`** | Rename the destructure (§2) |
-| `END_OPTIONS_NOT_SUPPORTED` | End options called for a daily or fixed-duration service | Branch on `durationRange.unitType` before calling |
-| `INVALID_DURATION_PROVIDED` | Chosen length falls outside the service's range | The response carries the allowed range — show it and return the customer to the picker |
-| `SLOT_NOT_AVAILABLE` | The slot was taken between selection and booking | Return to the slot picker and refresh availability |
-| Empty availability, no error | The service's resource type has **no resources** | A seed bug, not a frontend one — see `setup-rentals.md` STEP 2 |
-| Rentals mixed with appointments | A catalog read without the `appId` filter | Add `appId` to `query.filter` (§1) |
-| `NUMBER_OF_PARTICIPANTS_NOT_FOUND` | `numberOfParticipants` missing or `0` on the price preview | Send `1` — always 1 for a rental (§4) |
-| Price differs from what was shown | Price preview sent without `localStartDate`/`localEndDate`/`timeZone` | Send all three (§4) |
-| Booking created at the wrong location, or `location` silently empty | Read only `.location._id` (undefined) | Read both `.location.id ?? .location._id` (§5) |
-| Hunting for `WIX_APPS.rentals.*` or `seoTags.ItemType.RENTAL` | Neither exists | Use the **bookings** accessors — a rental detail page *is* a Bookings service page (§6) |
-| `.image.url` fails `tsc`, or images render broken | `media.mainMedia.image` is a **string** holding a `wix:image://` URI | `media.getImageUrl(...)` from `@wix/sdk` (§6) |
-
----
-
-## Out of scope
-
-**Cancellation.** A logged-in member can cancel their own rental:
-
-- A **single** rental (hourly, or daily on a 24/7 resource) cancels with `cancelBooking` and its current `revision`.
-- A **multi-day group** (daily on a working-hours resource) cancels with `cancelMultiServiceBooking` and the group's **`multiServiceBookingInfo.id`**, read back off any booking in the group.
-
-**⚠️ Read the booking back with `queryExtendedBookings`, filtered on the rentals `appId`.** Without an `appId` (or `createdByAppId`) filter of your own, the query applies a default one that covers Bookings but **not** rentals, and returns **0** results — a rentals booking that exists looks like it doesn't. Naming `appId` in the filter suppresses that default:
-
-```js
-  filter: { appId: RENTALS_APP_ID },
-```
-
-Refunds are the eCommerce Orders API, not Bookings. Also out of scope, as in bookings: waitlists, deposit/payment breakdowns, and multi-item rental carts.
-
-## Conclusion
-
-- Rentals is **`@wix/bookings`** — there is no `@wix/rentals`, and its absence is not a missing capability.
-- **Every catalog read filters on the rentals `appId`**, or a mixed site shows the wrong services.
-- **Hourly** = two availability calls (start → `timeSlots`, then end options → **`endOptions`**, hourly-only, `location` required, `serviceId` positional). **Daily** = one call with `timeSlotsPerDay: 1`, then walk consecutive days client-side.
-- **Daily storage follows the resource:** 24/7 → one booking (midnight to midnight-after, never set `allDay`); working hours → a sequential multi-service group whose id you must persist yourself.
-- **Price preview needs both local dates and the time zone**, or it silently returns a duration-blind price.
-- Booking, cart, checkout and confirmation are the **bookings** flow, with the rentals app id on the cart's `catalogReference` — **except** the anonymous-token confirmation step, which rentals must skip entirely (§5).
-- **The slot's location id must be read defensively** as `.location.id ?? .location._id` — the SDK type says `_id`, but the field stays `.id` on the wire.
-- **SEO and images are the bookings ones too** — `WIX_APPS.bookings.servicePageMetadata` and `seoTags.ItemType.BOOKINGS_SERVICE`; there is no rentals-specific accessor to find.

package/skills/wix-headless/references/inline-recipes/how-to-code-restaurant-orders.md

@@ -1,191 +0,0 @@
----
-name: "How to Code Restaurant Orders"
-description: The frontend cart/checkout contract for a Wix Restaurants Online-Ordering site — which SDK modules to import, how to read the ordering operation + fulfillment methods, the exact restaurant add-to-cart shape (appId = Orders app, options = operationId+menuId+sectionId, NOT variantId), and checkout via eCommerce. Specifies the *how* (modules + exact calls + failure modes); which menu/items to sell come from the request.
----
-**RECIPE**: How to Code a Wix Restaurants Ordering Frontend (Online Orders + eCommerce cart)
-
-A contract for the **frontend code** that lets a visitor **order** from a Wix Restaurants menu: reading the ordering operation and fulfillment methods, adding a menu item to the eCommerce cart with the restaurant `catalogReference`, and checking out. **This recipe is the *how* (which modules, which calls, which fields), not the *what*** — which menu/items to sell and how the page looks come from the request you're fulfilling.
-
-> **This recipe is for CODING ordering, not seeding it.** It assumes the backend already exists — a Restaurants **Menus** backend (menu → sections → items) **and** the Restaurants **Orders** app installed and configured (an `ENABLED` operation with fulfillment methods, every menu ordering-enabled). See `setup-restaurants.md` + `setup-restaurant-orders.md` for the backend. This recipe says nothing about creating any of it — only how to read and purchase from frontend code.
-
-> **Reading (displaying) the menu is a SEPARATE recipe — pair this with it.** `how-to-code-restaurants.md` covers listing menus/sections/items, assembling the hierarchy in `sectionIds`/`itemIds` order, reading `item.priceInfo.price`, and rendering images. That recipe is **display-only** (no cart). **This** recipe adds the **ordering** layer on top: it consumes the same `menus`/`sections`/`items` reads and needs each rendered item's `_id`, its section's `_id`, and the menu's `_id` to build a cart line. Don't duplicate the menu-reading here — read it there, order it here.
-
-> **⚠️ Reading rule — always append `.md?apiView=SDK` to every doc link below.** The Wix docs render two views of the same page. The **bare / REST view shows `id`**; the **`?apiView=SDK` view shows `_id`** — and the SDK is what your frontend calls. Reading the REST view by mistake is the most common source of the `entity.id`-is-`undefined` cart bug. Fetch the `.md?apiView=SDK` form directly; don't re-discover these with search.
-
----
-
-## The modules and the client (read this first)
-
-**Restaurants Orders app id** (a constant you need for the cart's `catalogReference.appId`):
-`9a5d83fd-8570-482e-81ab-cfa88942ee60`
-
-**⚠️ This is the ORDERS app id, NOT the Stores app id.** A restaurant menu item added to the cart must carry `appId: '9a5d83fd-…'` (Orders). Using the Stores id (`215238eb-…`) — muscle memory from `how-to-code-a-store.md` — makes eCommerce resolve the line against the wrong catalog and the add fails. Menu items are **not** Stores products.
-
-| Need | Package | Module (namespace) |
-|---|---|---|
-| Menus / sections / items (display) | `@wix/restaurants` | `menus` / `sections` / `items` — see `how-to-code-restaurants.md` |
-| The ordering operation (for `operationId`) | `@wix/restaurants` | `operations` |
-| Fulfillment methods (pickup/delivery to show) | `@wix/restaurants` | `fulfillmentMethods` |
-| Cart (add / get / checkout) | `@wix/ecom` | `currentCartV2` |
-| Redirect to hosted checkout | `@wix/redirects` | `redirects` |
-
-> Migrating from Cart V1 / Checkout V1? The code below is V2-only — see the [migration guide](https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/purchase-flow/cart-v2/migration-guide) for the before/after.
-
-**Auth / client — framework split:**
-- **Astro (Wix-managed):** authentication is ambient. Call `operations` / `fulfillmentMethods` / `currentCartV2` directly from server components and backend routes (`src/pages/api/*.ts`) — **no `createClient`, no `OAuthStrategy`, no `clientId`.**
-  ```js
-  import { operations, fulfillmentMethods } from '@wix/restaurants';
-  import { currentCartV2 } from '@wix/ecom';
-  const { operations: ops } = await operations.listOperations();
-  ```
-- **Non-Astro (Vite/React/Vue/static):** build one manual visitor client and reuse it:
-  ```js
-  import { createClient, OAuthStrategy } from '@wix/sdk';
-  import { menus, sections, items, operations, fulfillmentMethods } from '@wix/restaurants';
-  import { currentCartV2 } from '@wix/ecom';
-  import { redirects } from '@wix/redirects';
-
-  const client = createClient({
-    modules: { menus, sections, items, operations, fulfillmentMethods, currentCartV2, redirects },
-    auth: OAuthStrategy({ clientId: /* the project's PUBLIC OAuth client id */ }),
-  });
-  // then: await client.operations.listOperations(), await client.currentCartV2.addLineItemsToCurrentCart({...})
-  ```
-  The `clientId` is public, not a secret. A mis-wired public env var inlines as `undefined` and 400s every call.
-
----
-
-## The shapes you read (field cheat-sheet)
-
-These are **SDK read shapes** (`?apiView=SDK`), so entity ids are **`_id`**. Prices/fees are decimal **strings**. The cart-add body (under *Adding a menu item to the cart*) is a separate **write** shape; the `_id` rule applies to read **entities**, not to request params (note the redirect session's `checkoutId`, which is just the cart's `_id`).
-
-```jsonc
-// operations.listOperations()  →  { operations: [...] }   (no arguments)
-operation = {
-  _id,                        // → cart options.operationId   (NOT .id → undefined)
-  name, default,              // the auto-created ordering operation has default: true
-  onlineOrderingStatus,       // "ENABLED" when the site is taking orders
-  fulfillmentIds,             // ids of the fulfillment methods attached to this operation
-  defaultFulfillmentType,     // "PICKUP" | "DELIVERY"
-}
-
-// fulfillmentMethods.listFulfillmentMethods()  →  { fulfillmentMethods: [...] }
-fulfillmentMethod = {
-  _id, type,                  // "PICKUP" | "DELIVERY"
-  name, enabled,              // show only enabled:true to the visitor
-  fee, minOrderPrice,         // decimal STRINGS ("0", "5") — no currency symbol
-  pickupOptions,              // present when type PICKUP
-  deliveryOptions,            // present when type DELIVERY (deliveryTimeInMinutes, deliveryArea, …)
-}
-
-// item (from items.listItems — see how-to-code-restaurants.md)
-item = { _id, name, priceInfo: { price } }   // price is a decimal STRING; _id → cart catalogItemId
-
-// currentCartV2.getCurrentCart()  →  { cart: { _id, lineItems: [...] } }   // NOTE: returns { cart } — destructure it
-lineItem = { _id, name: { original }, quantityInfo: { confirmedQuantity }, pricing: { unitPrice: { amount } }, attributes: { image } }
-// price → pricing.unitPrice (ConvertedMoney, NO formatted string in V2 — format it yourself; .amount is site currency, .convertedAmount the buyer's display currency); qty → quantityInfo.confirmedQuantity; image → attributes.image (wix:image:// → resolve)
-
-// the cart's _id is the checkout id → pass to the redirect session:
-// redirects.createRedirectSession({ ecomCheckout: { checkoutId: cart._id }, callbacks })  →  { redirectSession: { fullUrl } }
-```
-
----
-
-## The features (build the ones the site needs)
-
-Each subsection is a **self-contained feature** — implement only what the site uses. The only ordering is *within* a feature (read the operation before you build a cart line that references it).
-
-### Reading the ordering operation (and the `_id` rule)
-
-Get the operation so you have the **`operationId`** every cart line needs. `listOperations()` takes **no arguments** and returns a plain array.
-
-```js
-const { operations: ops = [] } = await operations.listOperations();
-const op = ops.find((o) => o.onlineOrderingStatus === 'ENABLED') ?? ops.find((o) => o.default) ?? ops[0];
-const operationId = op._id;
-```
-Doc: <https://dev.wix.com/docs/api-reference/business-solutions/restaurants/online-orders/operations/list-operations.md?apiView=SDK>
-
-**⚠️ `list*` return the array as OPTIONAL — default it (`= []`) or the strict build fails.** `listOperations()` / `listFulfillmentMethods()` / `listItems()` type the returned array as `T[] | undefined`, so destructuring `{ operations: ops }` and calling `ops.find(...)` directly errors under `strict` / `astro check` (`'ops' is possibly 'undefined'`, TS18048) — a build-breaker on managed Astro. Default it in the destructure (`{ operations: ops = [] }`) or guard with `?? []`.
-
-**⚠️ CRITICAL: the entity id is `_id`, NOT `id`.** `operation.id` / `item.id` / `section.id` are `undefined` in SDK code. Feeding `operation.id` into `options.operationId` (or `item.id` into `catalogItemId`) sends an empty string and the add-to-cart fails. Use `_id` everywhere. (A surprising `id` field means you're reading the REST doc view — re-open with `?apiView=SDK`.)
-
-**Read the operation once and reuse `operationId`** for every add-to-cart on the page — don't call `listOperations()` per line item.
-
-### Reading fulfillment methods (pickup / delivery to show)
-
-List the methods to render the visitor's pickup/delivery choices (fee, minimum, type). Show only `enabled: true`.
-
-```js
-const { fulfillmentMethods: methods = [] } = await fulfillmentMethods.listFulfillmentMethods();
-const offered = methods.filter((m) => m.enabled);
-```
-Doc: <https://dev.wix.com/docs/api-reference/business-solutions/restaurants/online-orders/fulfillment-methods/list-fulfillment-methods.md?apiView=SDK> (default the array `= []` — see the optional-array note above)
-
-**⚠️ `listFulfillmentMethods` takes an OPTIONS object, not a query builder.** It accepts an optional `{ paging }` object and returns a `Promise` of `{ fulfillmentMethods }` directly — do **not** chain `.find()`/`.eq()` on it (that's the `queryProducts` builder pattern from stores; it does not apply here). `fee` and `minOrderPrice` are decimal **strings** — render them with your currency, and `Number(...)` only if you need arithmetic. Which method the buyer actually uses (and the delivery time slot) is chosen on the **hosted checkout**; listing here is for display, not a required pre-checkout step.
-
-### Adding a menu item to the cart — the restaurant `catalogReference`
-
-This is the one shape that differs materially from a Stores cart. Build a line item whose `catalogReference` names the **Orders app** and carries **`operationId` + `menuId` + `sectionId`** in `options`.
-
-```js
-await currentCartV2.addLineItemsToCurrentCart({
-  catalogItems: [{                                          // the write shape uses `catalogItems`
-    quantity,
-    catalogReference: {
-      catalogItemId: item._id,                              // the MENU ITEM's _id
-      appId: '9a5d83fd-8570-482e-81ab-cfa88942ee60',        // the ORDERS app id (not Stores)
-      options: {
-        operationId,                                        // from listOperations()
-        menuId,                                             // the _id of the menu the item is shown in
-        sectionId,                                          // the _id of the section the item is shown under
-      },
-    },
-  }],
-});
-```
-Doc: <https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/purchase-flow/cart-v2/add-line-items-to-current-cart.md?apiView=SDK>
-
-**⚠️ CRITICAL: `options` MUST carry `operationId`, `menuId`, AND `sectionId` — all three.** A restaurant line item is identified by *where in the menu it was ordered from*, not by a variant. Omitting any of the three makes eCommerce unable to resolve the item against the Restaurants catalog — Cart V2 rejects the add with an explicit error rather than accepting an invalid line. This is the restaurant analog of the store's mandatory `variantId`.
-
-**⚠️ CRITICAL: there is NO `variantId` here.** `options.variantId` is a **Stores** concept — menu items have no variants in this flow. Don't copy the store recipe's `variantId` resolution; a restaurant line uses `operationId`/`menuId`/`sectionId` instead. (Menu item *modifiers* — "extra cheese" — are a separate concern and out of scope for the basic order flow.)
-
-**⚠️ Thread `sectionId` and `menuId` from the render, not a lookup.** When you assemble the menu (menu → sections → items, per `how-to-code-restaurants.md`), each item is rendered **inside** a known section and menu — capture that `section._id` and `menu._id` at render time and pass them to the add-to-cart handler alongside `item._id`. Re-deriving an item's section afterward is unnecessary and error-prone; you already have it in the render context.
-
-Optional: `options.onlineOrderingPageUrl` (e.g. `"/online-ordering"`) lets the buyer click the cart line to return to the item — include it only if your site has such a page.
-
-### Checkout — redirect to the hosted checkout page
-
-The cart's `_id` **is** the checkout id — pass it into the redirect session's `ecomCheckout.checkoutId`. Read the current cart, then hand its id to a redirect session (identical to the storefront flow — restaurant orders ride on the same eCommerce checkout).
-Doc: <https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/purchase-flow/cart-v2/get-current-cart.md?apiView=SDK>
-
-```js
-const { cart } = await currentCartV2.getCurrentCart();   // NOTE: returns { cart } — destructure it
-const session = await redirects.createRedirectSession({
-  ecomCheckout: { checkoutId: cart._id },   // the cart's _id IS the checkout id
-  callbacks: { postFlowUrl: `${origin}/`, thankYouPageUrl: `${origin}/` },
-});
-window.location.href = session.redirectSession.fullUrl; // the hosted-checkout URL (fulfillment + time slot chosen here)
-```
-
-**⚠️ The cart's `_id` is the checkout id.** Pass `cart._id` into the redirect session's `ecomCheckout.checkoutId`. And `getCurrentCart()` returns **`{ cart }`** — destructure it, or `cart` is `undefined` and `cart._id` throws *"Cannot read properties of undefined (reading '_id')"*.
-
-**⚠️ CRITICAL: `origin` for `postFlowUrl`/`thankYouPageUrl` MUST be the `https://` published host — derive it from `window.location.origin`, NEVER `new URL(request.url).origin`.** The Headless redirect allowlist registers the site's **`https://`** host and treats `http://<same host>` as a different, unlisted origin. If you build the redirect session in a **server route** (`src/pages/api/*`), `new URL(request.url).origin` resolves to `http://` behind Wix's TLS-terminating proxy → the buyer's return redirect **403s** with *"… isn't listed as an allowed redirect domain."* Pass `window.location.origin` from the client into the route (or force the scheme to `https`). Doc: <https://dev.wix.com/docs/go-headless/getting-started/setup/manage-urls/add-allowed-redirect-domains>.
-
-**⚠️ LIVE PAID CHECKOUT PRECONDITION.** A visitor can add to cart and reach the hosted checkout with just this code, but **completing a paid order** needs the site to have a **premium plan and a configured payment method**. That's site provisioning, not a frontend bug — if checkout can't collect payment, the setup is incomplete, not the code.
-
-### Reading the price and the cart
-
-Menu item price is **`item.priceInfo.price`** — a decimal **string** with no currency symbol (see `how-to-code-restaurants.md`; the SDK `PriceInfo` type has only `price`, no `formattedPrice`). A cart line's price is **`lineItem.pricing.unitPrice`** / **`pricing.totalPrice`** — a `ConvertedMoney` `{ amount, convertedAmount }`; Cart V2 line items carry no preformatted price, so format it yourself. The currency lives on the cart, not the money object — format from `cart.customerInfo?.currencyCode ?? cart.businessInfo?.currencyCode` (see the *Formatting cart prices* section of `how-to-code-a-store.md` for the exact `Intl.NumberFormat` helper), e.g. `new Intl.NumberFormat(undefined, { style: 'currency', currency }).format(Number(pricing.totalPrice.convertedAmount ?? pricing.totalPrice.amount))`. Cart line images are `wix:image://` identifiers — resolve them with `media.getScaledToFillImageUrl(id, w, h, {})` (4 args), never raw (see the store/menu recipes' image callout).
-
----
-
-## Conclusion
-A correct Restaurants ordering frontend:
-- imports **`operations` / `fulfillmentMethods` from `@wix/restaurants`** (plus `menus`/`sections`/`items` for display) and **`currentCartV2` / `redirects`** from `@wix/ecom` / `@wix/redirects`;
-- uses **`_id`** (never `id`) for the operation, menu, section, and item;
-- reads the **`operationId`** once from `listOperations()` (the `ENABLED`/`default` operation) and reuses it;
-- adds menu items with the **Orders app id `9a5d83fd-…`** (never the Stores id) and `options` carrying **`operationId` + `menuId` + `sectionId`** (all three) — **no `variantId`**;
-- threads `menuId`/`sectionId` from the render context, not a re-lookup;
-- checks out by feeding the **current cart's `_id`** (the checkout id) to **`redirects`**, with an **`https://` `window.location.origin`** for the callbacks; the hosted checkout collects fulfillment + payment (which needs a premium plan + payment method).
-</content>