@wix/agent-skills 1.35.1 → 1.36.1

package/skills/wix-headless/references/inline-recipes/setup-rentals.md

@@ -1,254 +0,0 @@
----
-name: "Setup Rentals"
-description: Initializes a Wix Rentals backend — creates a resource type, the bookable resources (rooms, vehicles, equipment), and the rental services carrying serviceResources plus a duration range so customers pick their own length in hours or days. Rentals has no APIs of its own; it is Services V2 with rentals-specific field values. Specifies the *how* (calls + format); how many resources and services, their ranges and prices come from the request.
----
-**RECIPE**: Business Recipe – Initial Setup for Wix Rentals (Services V2 + Resources V2)
-
-> **Standard call shape (every curl below).** The `<AUTH>` placeholder is shorthand for `Authorization: Bearer <TOKEN>` only. Body-bearing requests also need `Content-Type: application/json`.
-
-A concise checklist for turning a freshly provisioned Wix site with the **Wix Rentals** app installed into a populated catalog of rentable resources.
-**Notice** that this recipe is **NOT** meant for coding purposes and is **ONLY** meant for initial Rentals backend setup. (The frontend read/booking contract is the sibling recipe `how-to-code-rentals.md`.)
-
-> **This recipe is the *how*, not the *what*.** What to seed — how many resource types and resources, how many services, whether they are hourly or daily, their duration ranges and prices — is determined by the request you're fulfilling. This recipe only specifies the calls and the request format; it does not decide quantities.
-
-> **⚠️ Wix Rentals has NO APIs of its own.** It runs on the **Wix Bookings** APIs with rentals-specific field values, so a rental offering is a Bookings *service* and a reservation is a Bookings *booking*. There is no `@wix/rentals` package and no `/rentals/` REST namespace — do not go looking for one, and do not report rentals as "not supported headlessly".
->
-> **The Wix Rentals doc set is four pages** — this recipe is distilled from them, and they are where to go when a task falls outside the common path:
-> - [About Wix Rentals](https://dev.wix.com/docs/api-reference/business-solutions/rentals/introduction.md) — the model, the app id, and the constraints
-> - [Wix Rentals and the Bookings APIs](https://dev.wix.com/docs/api-reference/business-solutions/rentals/wix-rentals-and-the-bookings-apis.md) — each rentals concept mapped to its Bookings API
-> - [About Wix Rentals Availability](https://dev.wix.com/docs/api-reference/business-solutions/rentals/about-wix-rentals-availability.md) — resource schedules, hourly vs daily, buffer time
-> - [Wix Rentals: Sample Flows](https://dev.wix.com/docs/api-reference/business-solutions/rentals/sample-flows.md) — the call sequences, including [Set up a rental service](https://dev.wix.com/docs/api-reference/business-solutions/rentals/sample-flows.md#set-up-a-rental-service), which is this recipe end to end
-
-> ### The invariants (read these before anything else)
-> A service is a rental because of **five field values**, all set at create time in STEP 4:
-> 1. **`appId` = `ff5d6eb1-65e4-4f9a-8b14-64d34c12cc2e`** — and it is **IMMUTABLE after create**. A service created without it is a plain Bookings service *forever*; no update converts it. This is the most expensive mistake in this recipe.
-> 2. **`serviceResources: [{ "resourceType": { "id": "<resourceTypeId>" }, "resourceIds": { "values": ["<resourceId>", …] } }]`** — list the resource type **and** its concrete resource ids. Availability comes from the listed ids: identical services return 48 time-slots with them and 0 without. (Dropping `serviceResources` altogether returns `MISSING_APPOINTMENT_RESOURCES` — see STEP 4.)
-> 3. **`primaryResourceType`** — the resource type GUID, which makes availability come from the rooms/vehicles instead of staff schedules. It must reference **one of the types listed in `serviceResources`**. Omitting it silently falls back to the **staff** resource type.
-> 4. **`form.id` = `3a2ea2ce-91f4-4617-ab24-629933c0c31a`** — the Rentals default booking form, provisioned at install and identical on every site. Omit it and you get the standard Bookings form instead.
-> 5. **`durationRange`** — with a single `unitType` (`HOUR` or `DAY`) and its matching `hourOptions`/`dayOptions`. Mutually exclusive with `sessionDurations`.
->
-> And one ordering rule: **resources must exist before the service** (STEP 2 before STEP 4), or availability is permanently empty.
->
-> **Rental services never use a category** — omit the field. The bookings "a category or it's invisible" rule is specific to Wix Bookings and does not apply to rentals. See STEP 3.
-
-> **API surfaces:** everything is on the **public** host `https://www.wixapis.com/bookings/...`. Services are **Services V2** (`…/bookings/v2/services`) — the method page's schema header shows an internal `…/_api/bookings/v2/services` form, **do not use that**. Resource types are `…/bookings/v2/resources/resource-types`, resources are `…/bookings/v2/resources`. The Wix Rentals **app id** is `ff5d6eb1-65e4-4f9a-8b14-64d34c12cc2e` (needed here on the service, and by the frontend for filtering + the cart).
-
----
-
-## Article: Steps for Setting Up Wix Rentals
-
-**YOU MUST** complete the following steps **in the given order** (1-5) without skipping any and **without requiring additional user input**. STEP 5 (attributes) runs only when the request calls for filterable resource properties. The **Attach images** step runs **only when imagery is on** — skip it entirely otherwise.
-
-**⚠️ CRITICAL ORDER REQUIREMENT: resource type (STEP 1) → resources (STEP 2) → services (STEP 4).** (STEP 3 is intentionally empty — rental services use no category.) A rental service declares its resource type in `serviceResources` and points at it via `primaryResourceType`, and its availability is derived from the *resources* in that type — so both must exist before the service. A service created against a resource type that holds **no resources has permanently empty availability**: it is created successfully, appears in the catalog, and can never be booked.
-
-**Check for pre-existing services first** — same demo-data cleanup as bookings, same rules. List with `POST https://www.wixapis.com/bookings/v2/services/query` (body `{"query": {"paging": {"limit": 100}}}`), and `DELETE https://www.wixapis.com/bookings/v2/services/<serviceId>` the install's own samples. **Do not assume every existing service is a sample** — if it isn't obviously install demo data, **ask the user first**. Full rationale: `setup-bookings.md` § "Check for pre-existing services first".
-
-### STEP 1: Create the resource type
-
-A **resource type** is the category of thing being rented — "Meeting rooms", "Vans", "Cameras". A service connects to exactly **one** resource type, and Wix derives that service's availability from the resources inside it. Create one resource type per kind of thing the request rents.
-
-```bash
-curl -X POST 'https://www.wixapis.com/bookings/v2/resources/resource-types' \
-  -H 'Authorization: <AUTH>' \
-  -H 'Content-Type: application/json' \
-  -d '{ "resourceType": { "name": "Meeting rooms" } }'
-```
-
-The response is `{ "resourceType": { "id": "<resourceTypeId>", … } }` — **keep each `id`**, STEP 2 and STEP 4 both need it. Full contract: <https://dev.wix.com/docs/api-reference/business-solutions/bookings/resources/resource-types-v2/create-resource-type.md>
-
-- **`name` is required, max 40 characters, and must be unique per site.** A duplicate returns `409 RESOURCE_TYPE_ALREADY_EXISTS_FOR_NAME` — query or rename rather than retrying the same name.
-- Sites have a cap on resource types (`429 MAX_NUMBER_OF_RESOURCE_TYPES_REACHED`). Create one per genuine category, not one per item.
-
-### STEP 2: Create the resources
-
-A **resource** is an individual bookable thing — "Room A", "Room B", "Van 3". Create one per rentable unit. Two resources of the same type mean two customers can rent in parallel.
-
-```bash
-curl -X POST 'https://www.wixapis.com/bookings/v2/resources' \
-  -H 'Authorization: <AUTH>' \
-  -H 'Content-Type: application/json' \
-  -d '{
-    "resource": {
-      "name": "Room A",
-      "typeId": "<RESOURCE_TYPE_ID_FROM_STEP_1>"
-    }
-  }'
-```
-
-Keep each resource's returned **`id`** — it's needed for attributes (STEP 5) and the handoff, **not** by the service.
-
-**A resource's `typeId` binds it to its type; the service then binds to those resources by listing their ids.** STEP 4's `serviceResources` names the resource *type* **and** its `resourceIds`, which is where the service's availability comes from. Add a resource later by updating the service's `resourceIds`.
-
-- **⚠️ Omit `workingHoursSchedules` — this is the deliberate seed default and it matters downstream.** ([Why, in detail](https://dev.wix.com/docs/api-reference/business-solutions/rentals/about-wix-rentals-availability.md#resource-schedules).) A resource with **no** working-hours schedule is bookable **24/7**. That keeps the seed to a single call per resource, *and* it makes a multi-day daily rental store as **one booking** rather than a linked group of per-day bookings. A resource **with** working hours splits every multi-day rental into one booking per working day, created through Create Multi Service Booking — a materially harder frontend flow (`how-to-code-rentals.md` § "Daily availability"). Seed 24/7 unless the request explicitly needs opening hours; the merchant can add hours from the dashboard later.
-- **Working hours, when the request genuinely needs them,** are a Schedules V3 schedule referenced by `workingHoursSchedules.scheduleId` — created separately, then attached. It is out of scope for a seed; note it in the handoff instead. Reference: <https://dev.wix.com/docs/api-reference/business-solutions/bookings/resources/resources-v2/create-resource.md>
-- **Locations** — `locationOptions.specificLocationOptions` binds a resource to business locations. Omit it for a single-location site (the default). When both `workingHoursSchedules` and `locationOptions` are set, **`workingHoursSchedules` takes precedence**.
-
-### STEP 3: No category — rental services don't use categories
-
-**⚠️ Rental services do not use categories at all. Omit `category` from the service payload entirely** — do not send `"category": {}`, a made-up id, or try to create one. There is no step here; the numbering is kept so STEP 4 keeps its name.
-
-This is the one place where the bookings invariant does **not** carry over. `setup-bookings.md` STEP 2 calls `category.id` critical because a Bookings service without one is hidden on the live site. **That rule is specific to Wix Bookings and does not apply to Wix Rentals** — rentals are surfaced through the `appId`-filtered catalog read, not through Bookings categories. Confirmed on a live Rentals site: services created with no category come back from that read with `hidden: false`, and the Rentals install's own demo service ships without one.
-
-On a Rentals-only site the categories API isn't reachable anyway — it belongs to the **Wix Bookings app**, so `POST …/bookings/v2/categories` returns **`428 APP_NOT_INSTALLED`**. That is expected: rentals don't use categories, so there is nothing to do here. If the site also runs Wix Bookings for plain services, the categories API works there — assign categories only to those Bookings services, never to rentals.
-
-### STEP 4: Create the rental services
-
-Create the services **one at a time** with `POST https://www.wixapis.com/bookings/v2/services` — one call per service, each with a top-level `service` object. A rental service is a normal **Services V2 `APPOINTMENT`** carrying the rentals-specific values.
-
-**⚠️ Do NOT use the bulk endpoint (`…/bookings/v2/bulk/services/create`) for rentals.** It creates the service correctly but attaches a **schedule tagged with the Wix Bookings app id instead of the Wix Rentals one**, and calendar events inherit their app id from the schedule — so every booking and every event on that service becomes invisible in the Rentals dashboard calendar. The service itself looks perfect, which is what makes this hard to spot. Verified on a live site: bulk-created schedules carry `13d21c63-b5ec-5912-8397-c3a5ddb27a97`; single-created ones carry the rentals app id. Use single create until that is fixed upstream. (Bulk is still fine for plain Wix Bookings services — see `setup-bookings.md`.)
-
-**⚠️ CRITICAL: the V2 service payload is FLAT** — name/description/tagLine are top-level, not nested under `info`. Price uses `value` (a **string**), not `amount`. Full field contract: <https://dev.wix.com/docs/api-reference/business-solutions/bookings/services/services-v2/create-service.md>
-
-**One hourly rental service, bookable 1–8 hours at $40/hour:**
-
-```json
-{
-  "service": {
-    "type": "APPOINTMENT",
-    "appId": "ff5d6eb1-65e4-4f9a-8b14-64d34c12cc2e",
-    "name": "Meeting Room",
-    "description": "A brand-appropriate description of what is being rented.",
-    "tagLine": "Short tagline",
-    "defaultCapacity": 1,
-    "serviceResources": [ {
-      "resourceType": { "id": "<RESOURCE_TYPE_ID_FROM_STEP_1>" },
-      "resourceIds": { "values": ["<RESOURCE_ID_FROM_STEP_2>"] }
-    } ],
-    "primaryResourceType": "<RESOURCE_TYPE_ID_FROM_STEP_1>",
-    "form": { "id": "3a2ea2ce-91f4-4617-ab24-629933c0c31a" },
-    "onlineBooking": { "enabled": true, "requireManualApproval": false, "allowMultipleRequests": false },
-    "schedule": {
-      "availabilityConstraints": {
-        "durationRange": {
-          "unitType": "HOUR",
-          "hourOptions": { "minDurationInMinutes": 60, "maxDurationInMinutes": 480 }
-        }
-      }
-    },
-    "payment": {
-      "rateType": "FIXED",
-      "fixed": { "price": { "value": "40.00", "currency": "USD" } },
-      "options": { "online": true, "inPerson": false }
-    },
-    "locations": [ { "type": "BUSINESS" } ]
-  }
-}
-```
-
-**`serviceResources` carries both levels.** `resourceType.id` is the type from STEP 1; `resourceIds.values` lists the individual resources from STEP 2 that this service can book (max **100** ids, max **8** `serviceResources` entries).
-
-**List the concrete `resourceIds`** — the service's availability comes from them. Verified on a live site: identical services returned **48** time-slots with `resourceIds` and **0** without. Add resources later by updating the service's `resourceIds`.
-
-**⚠️ Price decides how many services you create.** The rate lives on the **service**, not the resource, so resources that rent at **different rates must be separate services**, each pinning its own resource in `resourceIds`. Three meeting rooms at ₪60, ₪120 and ₪250 per hour are **three services** sharing one resource type — not one service with three resources. Resources that rent at the **same** rate can share a single service.
-
-**For a daily rental**, swap the duration range (everything else is identical):
-
-```json
-"durationRange": {
-  "unitType": "DAY",
-  "dayOptions": { "minDurationInDays": 1, "maxDurationInDays": 5 }
-}
-```
-
-**⚠️ CRITICAL FORMAT REQUIREMENTS:**
-
-- **`appId` must be the Wix Rentals app id** `ff5d6eb1-65e4-4f9a-8b14-64d34c12cc2e`, and it is **immutable after create** — a service created without it is a plain Bookings service forever, and no update can convert it. Getting this wrong is the single most expensive mistake in this recipe.
-- **`appId` also means the service does NOT appear in the Wix Bookings dashboard** — it appears in the Rentals dashboard. That is correct and expected; don't "fix" it.
-- **⚠️ `serviceResources` is REQUIRED and is the real cause of `MISSING_APPOINTMENT_RESOURCES` — do not trust the error text.** The message reads *"service of type appointment requires at least one staff member or service resource"*, which invites you to go check whether your resource type has resources in it. **That is a dead end** — the create fails even when the type is fully populated. What the service actually needs is the resource type declared **on the service**:
-  ```json
-  "serviceResources": [ {
-    "resourceType": { "id": "<resourceTypeId>" },
-    "resourceIds": { "values": ["<resourceId>"] }
-  } ]
-  ```
-  Verified on a live site: adding this field is what makes the create succeed. `resourceType.id` is the type from STEP 1; `resourceIds.values` lists the resources from STEP 2 this service can book. Max **8** `serviceResources` entries, max **100** ids each. **`resourceIds` supplies the service's availability** — list them (48 slots with, 0 without, otherwise identical). Add resources later by updating `resourceIds`.
-- **`primaryResourceType`** is the resource type **GUID** from STEP 1, and **must be one of the types listed in `serviceResources`**. It is what makes availability come from the rooms/vehicles rather than from staff schedules. Omitting it silently falls back to the **staff** resource type, which produces a normal staff-driven appointment service.
-- **`form.id` selects the booking form. Set it to the Wix Rentals default booking form — `3a2ea2ce-91f4-4617-ab24-629933c0c31a`.** Installing the Rentals app provisions that form, and because it is cloned from the template with the template's own id, **the GUID is the same on every site** — treat it as a constant, like the `appId`. Omit the field and the service uses the standard Wix Bookings form instead, so the rentals form's own fields won't be there. It's the Rentals app's own choice too: `RentalsProvisioner` sets it on every service it creates.
-- **`durationRange` and `sessionDurations` are mutually exclusive** — send one or the other, never both. `durationRange` also **can't be combined with `workingHours`** on the service.
-- **`unitType` selects which config object is read:** `HOUR` → `hourOptions`, `DAY` → `dayOptions`. Sending `dayOptions` with `unitType: "HOUR"` leaves the range unset.
-- **Ranges:** hourly `minDurationInMinutes`/`maxDurationInMinutes` are **30–1440**; daily `minDurationInDays`/`maxDurationInDays` are **1–8** for rentals. Min must be **≤** max. (The underlying Services V2 schema permits days up to 60; Wix Rentals documents 1–8 — stay inside 1–8.)
-- **One unit type per service.** A service is hourly *or* daily, never both. If the request wants a room by the hour **and** by the day, that is **two services**, each with its own price.
-- **Omit `staffMemberIds`.** Rentals are resource-driven, not staff-driven — `serviceResources` above is what satisfies the appointment-resource requirement. Never add a staff resource to get past `MISSING_APPOINTMENT_RESOURCES`; that reintroduces staff-based availability and produces a service that is no longer a rental in behaviour.
-- **Omit `category`.** Rental services don't use categories at all (STEP 3).
-- **`onlineBooking: { "enabled": true }` is required** — V2 rejects the create without it even though it reads as optional.
-- **`defaultCapacity`** is required; use `1` (one customer rents a given resource at a time; parallel capacity comes from having more *resources*, not higher capacity).
-- **`payment.options` — at least one of `online`/`inPerson` must be `true`**, even for free services. `NO_FEE` must pair with `online: false, inPerson: true`.
-- **Price is per unit** — per hour for `HOUR`, per day for `DAY`. Wix multiplies it out at booking time (hourly is prorated per minute: `minutes × price ÷ 60`). Do **not** pre-multiply into a whole-rental price.
-- **`locations[].type`** — use **`"BUSINESS"`**, never `"OWNER_BUSINESS"` (that enum belongs to `createBooking`'s slot location).
-- **Currency** — the site's business currency wins; a EUR-locale site stores `EUR` even if you send `USD`. Not an error.
-- **Imagery is opt-in** (`SEED.md` § "Entity images") — seed text-only, attach images in the pass-2 step below.
-
-**Reading the response.** A single create returns the created service under a top-level `service`:
-
-```json
-{ "service": { "id": "<serviceId>", "name": "…", "type": "APPOINTMENT",
-               "appId": "ff5d6eb1-65e4-4f9a-8b14-64d34c12cc2e",
-               "mainSlug": { "name": "<url-slug>", "custom": false },
-               "schedule": { "id": "<scheduleId>", "availabilityConstraints": { "durationRange": { … } } } } }
-```
-
-Keep each service's **`service.id`** and **`service.mainSlug.name`** (the frontend links by slug; if absent, derive it: lowercase, non-alphanumerics → hyphens). A failed create returns a normal error — retry that one service **once** with the same body; don't loop, and don't re-create ones that already succeeded.
-
-**Verify the range actually landed.** `durationRange` is a newer field and a silently-dropped range yields a service that looks fine and books as a fixed slot. Re-read one created service (`GET https://www.wixapis.com/bookings/v2/services/<serviceId>`) and confirm `schedule.availabilityConstraints.durationRange.unitType` is populated before moving on.
-
-### STEP 5: Resource attributes (only when the request wants filterable properties)
-
-Attributes are typed custom properties on a resource — `Capacity` (number), `Has projector` (boolean), `Bed type` (string) — used to describe resources on the site and to filter the catalog. Skip this step entirely unless the request calls for it.
-
-> **⚠️ The attributes API is the one surface here that really does live under `/_api/`.** Unlike Services V2 (where the `_api` form in the schema header is wrong and the public form is correct), the attributes reference's own examples call `https://www.wixapis.com/_api/attributes/v1/...`. Use the paths exactly as written below — don't "correct" them to a public form.
-
-**1 · Define each attribute once per site.** Keep each returned `attributeDefinition.id`.
-
-```bash
-curl -X POST 'https://www.wixapis.com/_api/attributes/v1/attribute-definitions' \
-  -H 'Authorization: <AUTH>' \
-  -H 'Content-Type: application/json' \
-  -d '{
-    "attributeDefinition": {
-      "name": "Capacity",
-      "valueType": "NUMBER",
-      "numberConfig": { "min": 1, "max": 20 },
-      "defaultValue": { "numberDefault": 2 },
-      "visibility": true
-    }
-  }'
-```
-
-**2 · Set values per resource.** The **resource id** is the `{entityId}` path segment. Each entry is matched by `attributeDefinitionId`, so only the listed attributes are created or updated.
-
-```bash
-curl -X POST 'https://www.wixapis.com/_api/attributes/v1/attribute-values/<RESOURCE_ID_FROM_STEP_2>/bulk-upsert' \
-  -H 'Authorization: <AUTH>' \
-  -H 'Content-Type: application/json' \
-  -d '{
-    "values": [ { "attributeDefinitionId": "<ATTRIBUTE_DEFINITION_ID>", "numberData": 4 } ],
-    "returnEntity": true
-  }'
-```
-
-The value key is typed — `numberData` for `NUMBER`, and the string/boolean equivalents for those `valueType`s; check the reference for the exact key rather than guessing.
-
-**3 · Reading them back for display** — filter to attributes whose `attributeDefinition.visibility` is `true`. **⚠️ The API does not enforce visibility server-side**, so an unfiltered render leaks attributes the merchant marked hidden.
-
-References: <https://dev.wix.com/docs/api-reference/business-solutions/bookings/resources/attributes/attribute-definition/create-attribute-definition.md> and <https://dev.wix.com/docs/api-reference/business-solutions/bookings/resources/attributes/attribute-value/bulk-upsert-attribute-values.md>
-
-### Attach images (imagery ON only — skip otherwise)
-
-Identical to the bookings flow, because it is the same Services V2 entity. Obtain the image per `references/IMAGE_GENERATION.md`, then `PATCH https://www.wixapis.com/bookings/v2/services/<serviceId>` writing under **`media.mainMedia`** and **`media.coverMedia`**, each `{ "image": { "id", "url", "width", "height" } }`, echoing the current `revision`.
-
-**⚠️ Writing the image under `media.image` returns `HTTP 200` but silently drops it** — confirm by re-querying the service and checking `media.mainMedia` is populated. Never block on image failure; leave the service text-only. Full shape and caveats: `setup-bookings.md` § "Attach images".
-
----
-
-## Conclusion
-
-Following these steps **in order** sets up a Wix Rentals site:
-
-- A **resource type** exists, and it **contains resources** — without resources the service's availability is permanently empty.
-- Every service carries the **Wix Rentals `appId`** (`ff5d6eb1-65e4-4f9a-8b14-64d34c12cc2e`), set at create time because it is **immutable** afterwards.
-- Every service carries **`serviceResources`** with concrete **`resourceIds`** listed — resource type alone gives 0 availability slots — plus **`primaryResourceType`**, so availability comes from the resources rather than from staff.
-- Every service carries **`form.id`** = the Rentals default booking form constant, so it uses the rentals form rather than the standard Bookings one.
-- Every service carries a **`durationRange`** with a single `unitType` and its matching `hourOptions`/`dayOptions` — never alongside `sessionDurations`.
-- **No category** is set — rental services don't use categories, and the bookings visibility rule doesn't apply to them. They are surfaced by the `appId`-filtered catalog read.
-- Resources are seeded **24/7** (no working-hours schedule), which keeps a multi-day daily rental to a single booking.
-- IDs kept for the coding handoff: `resourceTypeIds[]`, `resourceIds[]`, `serviceIds[]`, service `slug`s (`mainSlug.name`), and any `attributeDefinitionIds[]`.

package/skills/wix-headless/references/inline-recipes/setup-restaurant-experiences.md

@@ -1,73 +0,0 @@
----
-name: "Setup Restaurant Experiences"
-description: Seeds Wix Table Reservations **Experiences** — a reservation that IS a special dining occasion at the restaurant (chef's table, cheese pairing, tasting-menu evening), as opposed to a plain table booking or a Bookings service. Points to the live docs for the full create payload and carries only the earned gotchas the docs don't state (field-shape drift, payment policy, premium gating, when-to-use). The occasions/prices/schedule come from the request.
----
-**RECIPE**: Business Recipe – Experiences Setup for Wix Table Reservations (Experiences API)
-
-> **Standard call shape (every curl below).** `<AUTH>` = `Authorization: Bearer <TOKEN>` **and** `wix-site-id: <SITE_ID>`. Body-bearing requests also need `Content-Type: application/json`.
-
-## When to use experiences (and when NOT to)
-
-An **experience** is a **reservation that is itself a curated dining occasion at the restaurant** — it books seats at the restaurant's own reservation location but overrides the location's defaults with its own name, description, per-guest payment policy, party-size, schedule, and booking form. Reach for it when the brief names a **chef's table, cheese pairing, or tasting-menu evening**.
-
-- **Experience vs plain reservation:** a plain reservation just books a table; an experience books a *named, scheduled, often paid occasion*. Same booking mechanism, different intent.
-- **Experience vs `bookings`:** the separate `bookings` vertical is for a **service/appointment/class with a provider** (spa, tutor, studio). If a restaurant *hosts and seats* the occasion, it's an experience — not a booking. (See `CAPABILITIES.md` — "Experiences vs bookings".)
-
-## Prerequisites
-
-- The **Table Reservations app** is installed (`SETUP.md` §2). **Experiences are a feature of that app — there is no separate app to install.**
-- A **reservation location exists** — the install auto-provisions the default one (`setup-restaurant-reservations.md` STEP 1). Discover it and take its **`id`**; every experience is created against that `reservationLocationId`. No menu dependency.
-
-## The docs are the source of truth for the payload — read them, don't guess
-
-Read these `.md` twins directly (first priority; append `.md` to the article URL). This recipe deliberately does **not** re-inline the full schema — it changes, and the docs carry the complete, current field tree:
-
-- **About Experiences** (what they are, how they bind to reservations/locations/time-slots): <https://dev.wix.com/docs/api-reference/business-solutions/restaurants/reservations/experiences/introduction.md>
-- **Create Experience** (the full create payload + example): <https://dev.wix.com/docs/api-reference/business-solutions/restaurants/reservations/experiences/create-experience.md>
-- **Query / Get Experience**: <https://dev.wix.com/docs/api-reference/business-solutions/restaurants/reservations/experiences/query-experiences.md> · <https://dev.wix.com/docs/api-reference/business-solutions/restaurants/reservations/experiences/get-experience.md>
-- **Sample flow** (showcase + book an experience end-to-end): <https://dev.wix.com/docs/api-reference/business-solutions/restaurants/reservations/experiences/sample-flows.md>
-
-Endpoint: `POST https://www.wixapis.com/table-reservations/experiences/v1/experiences`.
-
-## The flow
-
-1. **Discover the reservation location** (`setup-restaurant-reservations.md` STEP 1) → keep `reservationLocationId`.
-2. **Create one experience per named occasion.** Build the body from the request (occasion name, per-guest price, party size, days/times, duration) per the **Create Experience** doc. Keep each returned `experience.id`. Set `configuration.visible: true` so it shows on the live site.
-3. Per the "simple seeds" default, create only the occasions the brief names (typically 1–3); don't invent a full calendar.
-
-Minimal shape (the doc has the complete tree — this is only the skeleton to orient against):
-
-```jsonc
-{ "experience": {
-  "reservationLocationId": "<reservationLocationId>",
-  "configuration": {
-    "displayInfo": { "name": "…", "shortDescription": "…" },
-    "paymentPolicy": { "paymentPolicyType": "PER_GUEST", "perGuestOptions": { "price": "55.00" } },
-    "onlineReservations": {
-      "partySize": { "min": 2, "max": 8 },
-      "minimumReservationNotice": { "number": 24, "unit": "HOURS" },
-      "maximumReservationNotice": { "number": 60, "unit": "DAYS" },
-      "approval": { "mode": "AUTOMATIC" },
-      "maxGuests": { "number": 16 },
-      "businessSchedule": { "durationInMinutes": 90, "entries": [
-        { "recurrence": "WEEKLY", "weeklyOptions": { "startDaysAndTimes": [ { "day": "FRIDAY", "time": "18:30" } ] } }
-      ] }
-    },
-    "visible": true
-  }
-} }
-```
-
-## Earned gotchas (what the docs won't tell you — verified against the live API)
-
-- **⚠️ Notice fields are FLAT under `onlineReservations`, not wrapped.** Send `onlineReservations.minimumReservationNotice` and `.maximumReservationNotice` **directly**. The Create-Experience doc *example* nests them inside a `noticePeriod` object — that wrapper is stale; the required-parameters list (same page) shows them flat, and the flat form is what the API accepts. Follow the parameter tree, not the example blob.
-- **Required at create** (creation 400s without them): `reservationLocationId`; `configuration.displayInfo.name`; `configuration.paymentPolicy.paymentPolicyType`; `configuration.onlineReservations.partySize.min/max`, `.approval.mode`, `.minimumReservationNotice.{number,unit}`, `.maximumReservationNotice.{number,unit}`, `.maxGuests.number`. (Confirm against the doc — the list evolves.)
-- **`paymentPolicyType`: `PER_GUEST` or `FREE`.** `PER_GUEST` needs `perGuestOptions.price` (decimal **string**, e.g. `"55.00"`; currency is the site's). `FREE` needs no price. Creating a `PER_GUEST` experience succeeds on a free site, but a guest **completing** a paid experience booking needs the same premium + payment provider that any paid reservation does (below).
-- **`businessSchedule.entries[]`** carries the recurrence: `WEEKLY` with `weeklyOptions.startDaysAndTimes[{ day, time }]` (`day` is `MONDAY`…`SUNDAY`, `time` is `"HH:mm"`), or `ONE_TIME` with `oneTimeOptions`. `durationInMinutes` sits on `businessSchedule`, not per entry.
-- **⚠️ Booking an experience is PREMIUM-GATED**, exactly like turning on online reservations (`setup-restaurant-reservations.md` STEP 3 → `428 PREMIUM_ONLY` on a free site). **Creating** the experience works on a free site; **booking** it at runtime needs the site to be premium with online reservations enabled. Record the precondition in the handoff; **don't fail the seed** over it.
-- **Cover image (opt-in):** `configuration.displayInfo.coverImage` takes a Wix Media image (`{ id, url, … }`) — attach it in the imagery pass (`IMAGE_GENERATION.md`) only when `imagery` is on; otherwise omit and the frontend renders a themed block.
-- **⚠️ Heads-up for the booking UI (not a seed step):** the experiences **sample-flow doc** (linked above) tells the frontend to call `getScheduledTimeSlots` with the experience GUID — **that parameter doesn't exist** (neither the SDK nor REST scopes slots to an experience), so it silently returns the *location's* slots. The frontend must instead project bookable times from the experience's own `businessSchedule`. Full detail: `how-to-code-restaurant-reservations.md` (Gotcha C).
-
-## Keep
-
-Nothing crosses into the handoff — experiences are read **live** on the frontend (`queryExperiences`). Track the created `experienceId`(s) only transiently (to confirm success / attach cover images). Frontend booking contract: `how-to-code-restaurant-reservations.md` (Experiences section).

package/skills/wix-headless/references/inline-recipes/setup-restaurant-orders.md

@@ -1,197 +0,0 @@
----
-name: "Setup Restaurant Orders"
-description: Configures Wix Restaurants **Online Ordering** on top of an already-seeded Menus backend. Installing the Orders app AUTO-PROVISIONS a working ordering setup (an ENABLED operation with Pickup + Delivery attached, and every menu ordering-enabled), so this recipe VERIFIES that baseline and CUSTOMIZES the fulfillment methods to the request — it does NOT build ordering from scratch. Specifies the *how* (calls + format); which methods/fees/hours and which menus come from the request.
----
-**RECIPE**: Business Recipe – Online-Ordering Setup for Wix Restaurants (Orders app)
-
-> **Standard call shape (every curl below).** The `<AUTH>` placeholder is shorthand for `Authorization: Bearer <TOKEN>` **and** `wix-site-id: <SITE_ID>`. Body-bearing requests also need `Content-Type: application/json`.
-
-A checklist for online ordering on a Wix site that already has a **Restaurants Menus** backend.
-**Notice** that this recipe is **NOT** meant for coding purposes and is **ONLY** meant for initial ordering setup.
-
-> **⚠️ THE ORDERS-APP INSTALL DOES ALMOST EVERYTHING — this recipe VERIFIES and CUSTOMIZES, it does NOT create ordering from scratch.** Installing the Orders app auto-provisions a **fully working** ordering setup with **zero** extra calls:
-> - one **operation** (`onlineOrderingStatus: "ENABLED"`, `default: true`, `defaultFulfillmentType: "PICKUP"`, a full `orderScheduling`);
-> - **three fulfillment methods already attached** to it — a `"Pickup"` (enabled), a `"Delivery Area #1"` (DELIVERY, RADIUS, enabled, `fee "0"`), and a `"DoorDash Drive"` (DELIVERY, provider-based, **disabled**);
-> - a **menu-ordering-settings** object per menu, each already `onlineOrderingEnabled: true` and bound to the operation.
->
-> So a site with a seeded menu is **already orderable (pickup + delivery) the moment the Orders app is installed.** The steps below **verify** that baseline and **reshape it to the request** (rename/re-fee/re-hour the auto methods, disable unwanted ones, add extra ones). If the request asks for nothing beyond "let people order," all steps are just confirmations — keep the auto-provisioned defaults and do only the verification (STEP 2 reshapes methods **only** when the request names specifics).
-
-> **⚠️ DEPENDS ON MENUS — the menu must exist.** A customer orders **menu items**, and each menu is bound to the ordering operation through a **menu-ordering-settings** object. This recipe assumes the **Menus** backend is already seeded (`setup-restaurants.md` — menu → sections → items, all `visible: true`) and its `menuId`(s) are in hand. Installing the **Orders** app **auto-installs the Menus app** and **auto-creates one menu-ordering-settings object per menu** — for menus that already exist *and* for menus created *after* install — each already `onlineOrderingEnabled: true` and bound to the operation. So whichever order you install Orders vs. seed menus, every menu ends up orderable automatically; STEP 3 only verifies it.
-
-> **This recipe is the *how*, not the *what*.** Which fulfillment methods to offer (pickup, delivery, or both), their fees / minimum-order amounts / hours / delivery area, and which menus are orderable come from the request you're fulfilling. This recipe only specifies the calls and the request format; it does not decide those quantities. Per the "simple seeds" default, **if the request names no ordering specifics, keep the auto-provisioned defaults** and do only the verification steps.
-
-> **⚠️ API surfaces — this vertical spans SEVERAL micro-services, each on its OWN host prefix** (unlike Menus, which is all under `restaurants/menus/v1`). Do not "normalize" them to a single prefix:
-> - **Operations** — `https://www.wixapis.com/restaurants-operations/v1/operations`
-> - **Fulfillment methods** — `https://www.wixapis.com/fulfillment-methods/v1/fulfillment-methods`
-> - **Menu ordering settings** — `https://www.wixapis.com/menu-ordering-settings/v1/menu-ordering-settings`
->
-> These are the **new** Wix Restaurants Orders APIs. A superseded cURL sample in the docs still shows the old `restaurants/v1/fulfillment-methods` host **and** a snake_case `fulfillment_method` wrapper — ignore both. Use the `fulfillment-methods/v1/...` host and the **camelCase `fulfillmentMethod`** wrapper (for both create and update).
-
-> **⚠️ Operations & operation groups are AUTO-provisioned — never create them.** There is **no create-operation / create-operation-group** call in this flow. On install Wix creates one operation group and, for a headless site with **no business location configured**, a single operation with `businessLocationId: "none"`. You **discover** that operation (STEP 1) and, only if customizing, **PATCH** it; you never POST one.
-
----
-
-## Article: Steps for Setting Up Wix Restaurants Online Ordering
-**YOU MUST** complete all the following steps **in the given order** (0-3) without skipping any and **without requiring additional user input**. Every step is idempotent — it verifies the auto-provisioned state and only writes when the request calls for a change or the state is wrong.
-
-### STEP 0: Configure the business location address (required for ordering to actually work)
-
-**⚠️ Online ordering needs a business location with a REAL address — without it, ordering is "testing only" and checkout breaks at runtime.** This is the #1 silent gap for ordering sites: the Wix docs are explicit — *"If locations aren't configured on a site, online ordering functionality is limited to testing only, and in some cases may not work as expected"* (<https://dev.wix.com/docs/api-reference/business-solutions/restaurants/about-business-locations.md>). A site provisions with a **default location that has no street address** (only an auto-defaulted country/city), which counts as *not configured*. Fix it here, before verifying the operation.
-
-The **default** business location is the one online ordering reads; its address also **propagates to Site Properties** (the site's business address that the Business Manager shows). Docs: Locations API <https://dev.wix.com/docs/api-reference/business-management/locations/introduction.md> · Update Location <https://dev.wix.com/docs/api-reference/business-management/locations/update-location.md>.
-
-1. **List locations** and take the default (`GET https://www.wixapis.com/locations/v1/locations` → the entry with `default: true`). Keep its **`id`** and **`revision`**. (There is normally exactly one, auto-provisioned.)
-2. **Overwrite it with a real address** via **Update Location** — `PUT https://www.wixapis.com/locations/v1/locations/<id>`. Use the address from the request; the timezone should match it.
-
-```bash
-curl -sS <AUTH> -X PUT "https://www.wixapis.com/locations/v1/locations/<id>" \
-  -d '{
-    "location": {
-      "id": "<id>", "revision": "<revision>", "default": true,
-      "name": "<Business name>", "timeZone": "Europe/Paris",
-      "email": "<email>", "phone": "<phone>",
-      "address": {
-        "country": "FR", "subdivision": "FR-75", "city": "Paris", "postalCode": "75001",
-        "streetAddress": { "number": "18", "name": "Rue des Lumières" },
-        "formattedAddress": "18 Rue des Lumières, 75001 Paris, France"
-      }
-    }
-  }'
-```
-
-**⚠️ CRITICAL — earned gotchas (verified against the live API):**
-- **Update Location is a FULL OVERRIDE, not a partial update** (the docs say so explicitly). Send the **whole** `location` object, not just the address — omitted fields are wiped. A partial "just the address" body is the classic *"it reported success but nothing changed / it's not in the Business Manager"* failure.
-- **Echo `"default": true`.** The default flag isn't in the documented request params, but omitting it on a full override reads as flipping it off and **400s** with `CHANGE_DEFAULT_FORBIDDEN`. (Good news: this API fails **loudly** — prefer it over a field-mask-less Site-Properties `PATCH`, which silently no-ops.)
-- **`revision` is mandatory** (from STEP 0.1) and increments each update; a stale one 400s.
-- **`address.country` is a 2-letter ISO-3166 code** (`"FR"`, `"US"`), not a full name.
-- **No default location at all?** (a bare Orders-only site can have none — operations then carry `businessLocationId: "none"`.) **Create** one instead: `POST https://www.wixapis.com/locations/v1/locations` with the same `location` body (no `id`/`revision`), then it becomes the site's location and operations auto-bind on first-location-add (see about-business-locations). Docs: <https://dev.wix.com/docs/api-reference/business-management/locations/create-location.md>.
-- **The operation's `businessLocationDetails` is a denormalized snapshot with eventual-consistency lag** — after the update it may briefly still show the old placeholder address (e.g. a "San Francisco" default). That's cosmetic and self-heals; checkout reads the configured location/site address, which is correct immediately. Don't loop trying to "force" the snapshot.
-
-**Where the address comes from:** the request. If the brief names the restaurant's address, use it. **If it doesn't, a real address is genuine owner info the skill can't invent** — set a clearly-marked placeholder and **flag prominently in the handoff/summary that the owner must set their real business address before ordering works** (this is exactly the "make it work end-to-end" gap). Pair this with the premium/payment precondition below.
-
-### STEP 1: Verify (and if needed enable) the operation
-
-List operations and take the one Wix created on install. Keep its **`id`** and **`revision`**.
-
-```bash
-curl -sS <AUTH> -X GET "https://www.wixapis.com/restaurants-operations/v1/operations"
-```
-
-Response (`operations[]`, sorted by created date ascending):
-
-```json
-{ "operations": [
-  { "id": "<operationId>", "revision": "2", "name": "Ordering page 1", "default": true,
-    "onlineOrderingStatus": "ENABLED", "defaultFulfillmentType": "PICKUP",
-    "fulfillmentIds": ["<deliveryId>", "<pickupId>", "<doordashId>"],
-    "orderScheduling": { "type": "ASAP", "asapOptions": { "preparationTime": { "type": "MAX_TIME", "maxTimeOptions": { "timeUnit": "MINUTES", "duration": 30 } }, "asapFutureHandlingType": "BUSINESS_DAYS_AHEAD_HANDLING", "businessDaysAheadHandlingOptions": { "daysCount": 0 } } },
-    "operationGroupId": "<groupId>", "businessLocationId": "none" }
-] }
-```
-
-**⚠️ CRITICAL:**
-- **Do not POST to create an operation** — there is none to create; use the one that already exists. If `operations[]` comes back **empty**, the Orders-app install hasn't finished provisioning — **wait briefly and retry the GET once**; do not create anything. Still empty after one retry → **fail loud** (install didn't complete).
-- **`onlineOrderingStatus` is normally already `"ENABLED"`** on the auto-created operation — nothing to do. Only if you see `"DISABLED"` (or you paused it), PATCH it on:
-  ```bash
-  curl -sS <AUTH> -X PATCH "https://www.wixapis.com/restaurants-operations/v1/operations/<operationId>" \
-    -d '{ "operation": { "revision": "<operationRevision>", "onlineOrderingStatus": "ENABLED" } }'
-  ```
-  Enum values: `ENABLED` / `DISABLED` / `PAUSED_UNTIL`. **`revision` is mandatory and must be current** (it increments by 1 each PATCH; a stale revision 400s). **If you PATCH `orderScheduling`, send the whole object** — it's overwritten wholesale, not merged.
-- For a locationless headless site `businessLocationId` is **`"none"`** — expected; it matches the menu's `"none"` so ordering binds. Don't set a location.
-- Read `fulfillmentIds` here — it lists the methods currently attached to the operation (STEP 2 needs it).
-
-### STEP 2: Reconcile the fulfillment methods to the request
-
-List the fulfillment methods the install created, then shape them to the request. **Which methods/fees/hours/areas the site should offer come from the request — this step only gives the calls.**
-
-```bash
-curl -sS <AUTH> -X GET "https://www.wixapis.com/fulfillment-methods/v1/fulfillment-methods"
-```
-
-The install ships three (all with an `America/..`-defaulted **San Francisco placeholder** address and time zone from the site's region): a `PICKUP` `"Pickup"` (enabled), a `DELIVERY` `"Delivery Area #1"` (RADIUS, enabled, `fee "0"`), and a `DELIVERY` `"DoorDash Drive"` (provider-based, **disabled**). Keep each `fulfillmentMethod.id` and `revision`.
-
-Do only what the request calls for:
-
-**(a) Customize an auto-created method** (rename, set fee/minimum/hours/area) — PATCH it, partial body is fine:
-
-```bash
-curl -sS <AUTH> -X PATCH "https://www.wixapis.com/fulfillment-methods/v1/fulfillment-methods/<methodId>" \
-  -d '{ "fulfillmentMethod": { "revision": "<methodRevision>", "name": "Delivery", "fee": "5", "minOrderPrice": "20" } }'
-```
-
-**(b) Disable a method the request doesn't want** — PATCH `enabled: false` (leave `"DoorDash Drive"` disabled unless the request wants a 3rd-party courier):
-
-```bash
-curl -sS <AUTH> -X PATCH "https://www.wixapis.com/fulfillment-methods/v1/fulfillment-methods/<methodId>" \
-  -d '{ "fulfillmentMethod": { "revision": "<methodRevision>", "enabled": false } }'
-```
-
-**(c) Add a method beyond the defaults** (e.g. a "Curbside" pickup) — create it, THEN attach it to the operation:
-
-```bash
-# create — camelCase `fulfillmentMethod` wrapper
-curl -sS <AUTH> -X POST "https://www.wixapis.com/fulfillment-methods/v1/fulfillment-methods" \
-  -d '{ "fulfillmentMethod": {
-        "type": "PICKUP", "name": "Curbside", "enabled": true, "fee": "0", "minOrderPrice": "0",
-        "availability": { "availableTimes": [ { "dayOfWeek": "MON", "timeRanges": [ { "startTime": { "hours": 9, "minutes": 0 }, "endTime": { "hours": 22, "minutes": 0 } } ] } ], "timeZone": "America/New_York" },
-        "pickupOptions": { "instructions": "Wait in your car." } } }'
-# → { "fulfillmentMethod": { "id": "<newId>", "revision": "1", ... } }   (address auto-defaults if omitted)
-```
-Then PATCH the operation to add `<newId>` to `fulfillmentIds` (the create does **not** attach it — see the callout):
-
-```bash
-curl -sS <AUTH> -X PATCH "https://www.wixapis.com/restaurants-operations/v1/operations/<operationId>" \
-  -d '{ "operation": { "revision": "<currentOperationRevision>", "fulfillmentIds": [ "<existingId1>", "<existingId2>", "<newId>" ] } }'
-```
-
-**⚠️ CRITICAL FORMAT REQUIREMENTS:**
-- **A newly created fulfillment method is NOT auto-attached to the operation** (after a create, `operation.fulfillmentIds` is unchanged). Only the *install's* three are attached automatically. So whenever you **create** a method, you must **PATCH the operation's `fulfillmentIds`** to include it (pass the full array — existing ids **plus** the new one), or it won't be offered at checkout. Customizing/disabling an *existing* attached method needs no re-attach.
-- **Attach each fulfillment method to exactly one operation** — Wix warns that sharing a method across operations breaks ordering.
-- **Wrap create/update bodies in `fulfillmentMethod`** (camelCase). **`fee` and `minOrderPrice` are decimal STRINGS** (`"0"`, `"5"`, `"20"`), never numbers. Currency is site-derived — send none.
-- **`enabled: true`** to offer a method. **`availability.availableTimes[]`** is one entry per open weekday, each `timeRanges: [{startTime,endTime}]` (`hours` 0-23, `minutes` 0-59); `availability.timeZone` is required but Wix overrides it with the site's language-and-region zone, so any valid IANA zone is accepted.
-- **`pickupOptions`** for `PICKUP`, **`deliveryOptions`** (with a `deliveryArea`) for `DELIVERY` — send the one matching `type`. Omitting the pickup `address` is fine; it defaults from the operation.
-- **`revision` is mandatory on every PATCH** and increments by 1 each update; a stale one 400s.
-- Retry a failed create/update **once** with the same format; do not loop.
-
-> **The San Francisco / `fee "0"` defaults are placeholders.** They're harmless for a locationless demo site (a visitor can still build a cart). Only override the delivery `deliveryArea` / pickup `address` when the request gives a real location; otherwise leave them.
-
-### STEP 3: Verify each menu is orderable
-
-Menu-ordering-settings are auto-created **and auto-enabled** per menu (both pre- and post-install menus), so this is normally a confirmation. List them and check each menu the request marks orderable.
-
-```bash
-curl -sS <AUTH> -X POST "https://www.wixapis.com/menu-ordering-settings/v1/menu-ordering-settings/query" -d '{ "query": {} }'
-```
-
-Response — one object per menu; match by **`menuId`**:
-
-```json
-{ "menuOrderingSettings": [
-  { "id": "<settingsId>", "revision": "1", "operationId": "<operationId>", "menuId": "<menuId>",
-    "onlineOrderingEnabled": true, "availability": { "type": "ALWAYS_AVAILABLE", "timeZone": "America/New_York" } }
-] }
-```
-
-**⚠️ CRITICAL:**
-- **Normally every entry is already `onlineOrderingEnabled: true` with `operationId` set** — nothing to do; just confirm it. Only if an entry shows `onlineOrderingEnabled: false` or `operationId: "none"` (or the request wants a menu *not* orderable), PATCH it:
-  ```bash
-  curl -sS <AUTH> -X PATCH "https://www.wixapis.com/menu-ordering-settings/v1/menu-ordering-settings/<settingsId>" \
-    -d '{ "menuOrderingSettings": { "revision": "<settingsRevision>", "operationId": "<operationId>", "onlineOrderingEnabled": true, "availability": { "type": "ALWAYS_AVAILABLE", "timeZone": "America/New_York" } } }'
-  ```
-- **`availability.type: "ALWAYS_AVAILABLE"`** makes the menu orderable during the operation's hours; a `timeZone` is required. **`revision` is mandatory** and increments per update.
-- The settings object's `businessLocationId` (inherited from its menu, `"none"` for a locationless site) must match the operation's `businessLocationId` for ordering to bind — both are `"none"` here, so they match. Don't override it.
-- To make a menu **display-only** (not orderable), PATCH that one to `onlineOrderingEnabled: false`; leave the rest enabled.
-
-> **⚠️ LIVE CHECKOUT PRECONDITIONS (note, don't fail).** A visitor can browse the orderable menu and build a cart with just this setup, but **completing an order** end-to-end needs three things beyond the seed: **(1) a configured business location with a real address** (STEP 0 — without it ordering is "testing only"); **(2) a premium plan**; and **(3) a configured payment method** (checkout rides on Wix eCommerce). STEP 0 handles (1) via API; (2) and (3) are **dashboard/premium provisioning** the skill can't do headlessly. Surface all three in the handoff; do **not** fail the seed over them.
-
----
-
-## Conclusion
-Following these steps confirms/completes online ordering for a site whose **Menus** backend is already seeded:
-- A **business location with a real address is configured first** (STEP 0, Update Location full-override) — without it ordering is "testing only"; the address propagates to Site Properties. If the brief gives no address, a placeholder is set and the owner is flagged to fix it.
-- The **Orders-app install already produced a working setup** — an `ENABLED` operation with Pickup + Delivery attached and every menu ordering-enabled; this recipe **verifies** that and **reshapes it to the request**, it does not build it from nothing.
-- The **operation** is discovered, never created (operations/groups are auto-provisioned); it stays `onlineOrderingStatus: "ENABLED"`.
-- **Fulfillment methods** are reconciled to the request — auto-created ones customized (decimal-string `fee`/`minOrderPrice`, weekly `availability`), unwanted ones disabled, extra ones created **and attached** to the operation via `fulfillmentIds` (a create does not auto-attach).
-- Every orderable **menu** is confirmed `onlineOrderingEnabled: true` and bound to the operation through menu-ordering-settings.
-- Each Orders micro-service is called on its **own host prefix** (`restaurants-operations` / `fulfillment-methods` / `menu-ordering-settings`) with the camelCase `fulfillmentMethod` wrapper; `revision` is passed on every PATCH. Real paid checkout additionally needs a premium plan + payment method (handoff note).
-</content>