@wix/agent-skills 1.15.0 → 1.16.0

package/skills/wix-manage/references/blog/how-to-create-blog-posts.md

@@ -1,6 +1,6 @@
 ---
 name: "How to Create Blog Posts"
-description: Creates and publishes blog posts using Blog Posts API. Covers Ricos rich content format, image upload via Media Manager, category/tag assignment, and bulk post creation.
+description: Creates and publishes blog posts using Blog Posts API. Covers resolving the required author memberId (including creating an author member when the site has none), Ricos rich content format, image upload via Media Manager, category/tag assignment, and bulk post creation.
 ---
 
 **Article: Create and Publish Blog Posts with Rich Content and Images**
@@ -17,16 +17,40 @@ This article demonstrates how to create and immediately publish blog posts using
 
 **IMPORTANT**: When calling the Blog API as a 3rd-party app (not as the site owner), `draftPost.memberId` is **required**. The API will reject requests with "Missing post owner information" if omitted.
 
-1. Query site members to get a valid member ID using [List Members](https://dev.wix.com/docs/api-reference/crm/members-contacts/members/member-management/members/list-members):
+A `memberId` is the `id` of a **site member** (Wix Members). Only the Members API produces one. Run the two steps below in order and stop as soon as you have an id — do not go looking for an author id anywhere else (see [What is not a memberId](#what-is-not-a-memberid)).
+
+1. Query site members using [List Members](https://dev.wix.com/docs/api-reference/crm/members-contacts/members/member-management/members/list-members):
 
    ```bash
    curl -X GET "https://www.wixapis.com/members/v1/members?fieldsets=PUBLIC&paging.limit=1" \
      -H "Authorization: <AUTH>"
    ```
 
-2. Use the `id` field from the response as `draftPost.memberId` when creating the blog post. This member will be the post author.
+   If the response contains a member, use `members[0].id` as `draftPost.memberId` and skip step 2. That member becomes the post author.
+
+2. **If the site has no members yet** — the response is `{"members": [], "metadata": {"count": 0, "total": 0, ...}}` — create the author member yourself with [Create Member](https://dev.wix.com/docs/api-reference/crm/members-contacts/members/member-management/members/create-member). This is the normal case on a new site or a site that only has Blog installed: nobody has signed up, so there is no member to reuse. Creating the author is a prerequisite of the post the user asked for, not a separate decision — create it, then say so in your summary.
+
+   ```bash
+   curl -X POST "https://www.wixapis.com/members/v1/members" \
+     -H "Authorization: <AUTH>" \
+     -H "Content-Type: application/json" \
+     -d '{
+       "member": {
+         "loginEmail": "blogauthor@example.com",
+         "contact": { "firstName": "Blog", "lastName": "Author" }
+       }
+     }'
+   ```
+
+   Use `member.id` from the response as `draftPost.memberId`. The new member comes back with `status: "APPROVED"`, and its `profile.nickname` is derived from the contact name. That nickname is the author name the blog displays, so pass the name the user wants shown (or set `member.profile.nickname` explicitly). If the user named an author, use their name; otherwise a generic author like the example above is fine.
+
+#### What is not a memberId
+
+These are the wrong places to look, and probing them costs a round trip each:
 
-   > **Note**: The member ID must belong to an existing site member or collaborator. If the members query returns no results, you may need to create a member first or use the site owner's member ID.
+- **Site collaborators / contributors are Wix *users*, not site members.** The [Contributors API](https://dev.wix.com/docs/api-reference/account-level/user-management/sites/contributors/introduction) returns account and user ids, which the Blog API will not accept as a `memberId`.
+- **A contact is not a member.** Querying [Contacts](https://dev.wix.com/docs/api-reference/crm/members-contacts/contacts/contacts/introduction) returns contact ids; only members have a `memberId`. On a site with no members the contacts query is usually empty too.
+- **`GET https://www.wixapis.com/identity/v1/users` returns 404.** There is no site-scoped identity endpoint to read the site owner from. Do not try it.
 
 ### Part 1: Import External Images to Wix Media Manager
 
@@ -264,7 +288,7 @@ The natural intuition is "the bulk endpoint reuses the single-post `{draftPost:
 - Never mock blog posts or media IDs - always use the APIs to import images and create posts
 - Always read the full documentation of methods before implementation
 - External images MUST be imported via Import File API before use in blog posts - direct external URLs will not work
-- For 3rd-party app integrations, `memberId` is mandatory - use the [List Members](https://dev.wix.com/docs/api-reference/crm/members-contacts/members/member-management/members/list-members) API if needed to get member ID
+- For 3rd-party app integrations, `memberId` is mandatory - get it from [List Members](https://dev.wix.com/docs/api-reference/crm/members-contacts/members/member-management/members/list-members), and if the site has no members yet, create one with [Create Member](https://dev.wix.com/docs/api-reference/crm/members-contacts/members/member-management/members/create-member) (see Part 0). Never substitute a contact id, a collaborator/contributor id, or a Wix user id for a `memberId`
 - Use ONLY the file ID (without `wix:image://v1/` prefix) for both cover images and embedded images
 - Rich content IMAGE nodes require both `width` and `height` properties in the `image` object
 - Images with `"operationStatus": "PENDING"` from import can be used immediately in blog posts
@@ -290,6 +314,7 @@ The natural intuition is "the bulk endpoint reuses the single-post `{draftPost:
 | Error                                      | Cause                       | Solution                                                            |
 | ------------------------------------------ | --------------------------- | ------------------------------------------------------------------- |
 | "Missing post owner information"           | `memberId` not provided     | Add `draftPost.memberId` - see Part 0 for how to get one            |
-| "memberIds ... do not exist"               | Invalid member ID           | Query members first using List Members API to get valid IDs         |
+| "memberIds ... do not exist"               | Invalid member ID           | The id is not a site member's id (e.g. a contact, contributor, or Wix user id). Re-resolve it with Part 0 |
+| List Members returns `"total": 0`          | Site has no members yet     | Create the author member with Create Member - Part 0, step 2. Do not query contacts, contributors, or identity endpoints instead |
 | "Expected a paragraph node but found TEXT" | Invalid Ricos structure     | Wrap TEXT nodes in PARAGRAPH nodes (see structure rules above)      |
 | Image not displaying                       | Using external URL directly | Import image via Media Manager first, then use the returned file ID |

package/skills/wix-manage/references/bookings/booking-service-policy-setup.md

@@ -89,7 +89,9 @@ Query the service to confirm policies are applied correctly. The service should
 
 ## API Documentation References
 
-- [Booking Policies API](https://dev.wix.com/docs/api-reference/business-solutions/bookings/policies/introduction)
+- [Query Booking Policies](https://dev.wix.com/docs/api-reference/business-solutions/bookings/policies/booking-policies/query-booking-policies) — `POST https://www.wixapis.com/bookings/v1/booking-policies/query`
+- [Update Booking Policy](https://dev.wix.com/docs/api-reference/business-solutions/bookings/policies/booking-policies/update-booking-policy) — `PATCH https://www.wixapis.com/bookings/v1/booking-policies/{bookingPolicy.id}`
+- [Create Booking Policy](https://dev.wix.com/docs/api-reference/business-solutions/bookings/policies/booking-policies/create-booking-policy) — `POST https://www.wixapis.com/bookings/v1/booking-policies`
 - [Bulk Create Services](https://dev.wix.com/docs/api-reference/business-solutions/bookings/services/services-v2/bulk-create-services) — `POST https://www.wixapis.com/bookings/v2/bulk/services/create`
 - [Update Service](https://dev.wix.com/docs/api-reference/business-solutions/bookings/services/services-v2/update-service) — `PATCH https://www.wixapis.com/bookings/v2/services/<SERVICE_ID>`
 - [Query Services](https://dev.wix.com/docs/api-reference/business-solutions/bookings/services/services-v2/query-services) — `POST https://www.wixapis.com/bookings/v2/services/query`

package/skills/wix-manage/references/bookings/bookings-dashboard-navigation.md

@@ -0,0 +1,63 @@
+---
+name: "Bookings Dashboard Navigation"
+description: "Builds direct links to Wix Bookings dashboard pages on manage.wix.com — services list, edit a specific service, calendar, booking list, staff, availability, resources, and settings pages. Pairs each main Bookings entity with its read API so you can fetch an entity and hand back a 'view it in your dashboard' link. Use when the user asks where something is in the Wix dashboard, wants a direct link to a dashboard page, or you need a dashboard URL to include with the result of an API operation."
+---
+
+# Bookings Dashboard Navigation
+
+Build direct links into the Wix Bookings pages of a site's dashboard. For the general URL contract (metaSiteId, fallbacks, redirects), see [Dashboard Navigation](../dashboard-navigation/dashboard-navigation.md).
+
+All Wix Bookings (app ID `13d21c63-b5ec-5912-8397-c3a5ddb27a97`) pages live under:
+
+```
+https://manage.wix.com/dashboard/{metaSiteId}/bookings/{route}
+```
+
+## Main Pages
+
+| Page | URL after `/dashboard/{metaSiteId}/` | What it manages |
+|---|---|---|
+| Services list | `bookings/services` | All services (appointments, classes, courses) |
+| Create service | `bookings/services/form` | New service form |
+| Edit service | `bookings/services/form/{serviceId}` | A specific service |
+| Service templates | `bookings/services/templates-catalog` | Create a service from a template |
+| Calendar | `bookings/calendar` | Sessions and daily schedule |
+| Booking list | `bookings/bookings/bookings-list` | All bookings in a table view |
+| Staff list | `bookings/staff` | Staff members |
+| Staff details | `bookings/staff/details/{staffMemberId}` | A specific staff member |
+| Availability | `bookings/availability` | Staff working hours / availability management |
+| Default business hours | `bookings/availability/default-hours` | The default weekly hours |
+| Resources | `bookings/resource-management/resource-types` | Resource types (rooms, equipment) |
+| Bookings settings | `bookings/settings` | Settings hub |
+| Booking policies | `bookings/settings/policies` | Cancellation / booking policies |
+| Reminders | `bookings/settings/reminders` | Email & SMS reminders |
+| Booking form | `bookings/settings/booking-form-page` | The customer booking form |
+| Apps & integrations | `bookings/integrations` | Bookings integration channels |
+
+Entity-specific links (`{serviceId}`, `{staffMemberId}`) accept the entity's ID appended as an extra path segment. Query params can follow (e.g. `?referralInfo=...`).
+
+Older link formats (`bookings/scheduler/owner/...`) still redirect to the current pages, so links found in existing content keep working.
+
+## Pairing Entities with Their Read APIs
+
+Fetch the entity via REST, then link the matching dashboard page. All calls use `https://www.wixapis.com` with an `Authorization` header.
+
+| Entity | Read API | Dashboard link |
+|---|---|---|
+| Service | `POST /bookings/v2/services/query` · `GET /bookings/v2/services/{serviceId}` | `bookings/services/form/{serviceId}` (edit) or `bookings/services` (list) |
+| Booking | `POST /bookings/v2/extended-bookings/query` | `bookings/bookings/bookings-list` |
+| Staff member | `POST /bookings/v1/staff-members/query` | `bookings/staff/details/{staffMemberId}` |
+| Session / event | `POST /calendar/v3/events/query` | `bookings/calendar` |
+| Resource type | Resources v2 APIs (`/bookings/v2/resources/...`) | `bookings/resource-management/resource-types` |
+| Booking policy | Services API `bookingPolicy` fields | `bookings/settings/policies` |
+
+Example — after creating a service, hand back its edit link:
+
+```
+Created "Deep Tissue Massage".
+Manage it here: https://manage.wix.com/dashboard/{metaSiteId}/bookings/services/form/{serviceId}
+```
+
+## Notes
+
+- Pages marked with an entity ID also work without it (they fall back to the list/create state).

package/skills/wix-manage/references/bookings/create-booking-service-from-prompt.md

@@ -1,13 +1,13 @@
 ---
 name: "Create Booking Service from Prompt"
-description: "Create a booking service from a user prompt — e.g. 'create a yoga class for $50', 'set up consultations for $75', 'add a personal training appointment', 'create a 6-week photography workshop'. Determines the service type (APPOINTMENT, CLASS, or COURSE) and delegates to the type-specific recipe."
+description: "Create a booking service from a user prompt — e.g. 'create a yoga class for $50', 'set up consultations for $75', 'add a personal training appointment', 'create a 6-week photography workshop', 'create a hidden free test course with 8 online sessions'. Determines the service type (APPOINTMENT, CLASS, or COURSE) and delegates to the type-specific recipe. For COURSE services with session dates/counts, follow the course recipe's separate Calendar bulkCreateEvents step; Services V2 alone does not create bookable course sessions."
 ---
 
 # Create Booking Service from Natural Language Prompt
 
 ## When to Use
 
-- User describes a service they want to create using natural language (e.g., "create a yoga class for $50", "set up consultation sessions", "add a personal training appointment")
+- User describes a service they want to create using natural language (e.g., "create a yoga class for $50", "set up consultation sessions", "add a personal training appointment", "create a hidden free test course with 8 online sessions")
 - The intent is autonomous creation — fill in reasonable defaults rather than asking the user for every field
 
 ## Step 1: Determine Service Type
@@ -16,7 +16,7 @@ description: "Create a booking service from a user prompt — e.g. 'create a yog
 |---|---|---|
 | consultation, appointment, meeting, 1-on-1, one-on-one, session | `APPOINTMENT` | [Create Appointment Service](./create-appointment-service.md) |
 | class, yoga, pilates, group session, group workout, bootcamp class | `CLASS` | [Create Class Service](./create-class-service.md) |
-| workshop, program, course, training program, multi-session | `COURSE` | [Create Course Service](./create-course-service.md) |
+| workshop, program, course, training program, multi-session, fixed series, 8 sessions | `COURSE` | [Create Course Service](./create-course-service.md) |
 | (unclear or unspecified) | `APPOINTMENT` | [Create Appointment Service](./create-appointment-service.md) |
 
 ## Step 2: Follow the Type-Specific Recipe
@@ -26,5 +26,6 @@ Once the service type is determined, follow the corresponding recipe linked abov
 1. Gathering business context (staff where required, categories, duplicate check)
 2. Applying type-specific defaults (pricing, capacity, duration, staff assignment)
 3. Creating the service via `bulkCreateServices`
-4. Navigating to the service form for user review
-5. Providing a summary of what was created and assumptions made
+4. For COURSE services with session dates/counts, creating separate Calendar events via `bulkCreateEvents` on the returned `service.schedule.id`
+5. Navigating to the service form for user review
+6. Providing a summary of what was created and assumptions made

package/skills/wix-manage/references/bookings/create-course-service.md

@@ -1,6 +1,6 @@
 ---
 name: "Create Course Service"
-description: "Create a course booking service — e.g. 'create a 6-week photography workshop', 'set up a training program', 'add a bootcamp course for $300', 'create a teacher training course'. Handles group capacity, full-course pricing, and fixed series defaults via bulkCreateServices API. Staff assignment is not used for courses."
+description: "Create a course booking service — e.g. 'create a 6-week photography workshop', 'set up a training program', 'add a bootcamp course for $300', 'create a hidden free test course with 8 sessions'. Handles group capacity, full-course pricing, bulkCreateServices, and separate course session events via bulkCreateEvents. Staff assignment is not used for courses."
 ---
 
 # Create Course Service from Prompt
@@ -8,6 +8,7 @@ description: "Create a course booking service — e.g. 'create a 6-week photogra
 ## When to Use
 
 - User wants to create a multi-session course: "create a training program", "set up a 6-week workshop", "add a bootcamp course", "create a teacher training course"
+- User wants a free or hidden test COURSE with specific session dates/counts, such as "create a hidden free test course with 8 online sessions"
 - The service type is COURSE — a fixed series with pre-defined start and end dates
 - Customers must book the entire course (all sessions), unlike CLASS where they can pick individual sessions
 - For general service creation where the type is ambiguous, see [Create Booking Service from Prompt](./create-booking-service-from-prompt.md)
@@ -91,6 +92,8 @@ curl -X POST 'https://www.wixapis.com/bookings/v2/categories' \
 
 **CRITICAL: COURSE services do NOT use `staffMemberIds` or `sessionDurations`.** These fields are ignored. Use `defaultCapacity` instead.
 
+Do not put session dates under `course.sessions`, `CourseSession`, or any similar nested field in the Services V2 create/update payload. Services V2 creates the course service and returns a `service.schedule.id`; it does not create bookable course sessions from nested `course` data. A course with no Calendar events can be created successfully but appear as ended or unavailable on the service page.
+
 **Paid course:**
 
 ```bash
@@ -148,23 +151,44 @@ curl -X POST 'https://www.wixapis.com/bookings/v2/bulk/services/create' \
 
 - Do **NOT** include `staffMemberIds` — it is ignored for COURSE services
 - Do **NOT** include `schedule.availabilityConstraints.sessionDurations` — not used for COURSE
+- Do **NOT** include `course.sessions` or inferred `CourseSession` objects in the service payload — accepted or ignored nested course data does not make sessions bookable
 - `defaultCapacity` is **required** — sets max participants for the entire course
 - Customers must book the **entire course** (all sessions), not individual sessions
 - After creation, course sessions must be scheduled separately via `bulkCreateEvents` using the returned `service.schedule.id` (see [Create and Update Booking Services](./create-and-update-booking-services.md))
+- If the user asked you to create the course and gave the session count/times, the job is not complete after `bulkCreateServices`; continue by creating the Calendar events, then verify the service has future events before telling the user it is ready
 
 Save the `serviceId` from the response: `results[0].item.service.id`
+Save the `service.schedule.id` from the response for the follow-up `bulkCreateEvents` request.
+
+---
+
+## Step 4: Create Course Session Events
+
+If the user specified session dates, times, or a session count, create the course events immediately after the service exists:
+
+1. Read `results[0].item.schedule.id` from the service create response.
+2. Query or create the resource/staff member that should appear on the course events and use its `resourceId`.
+3. Call `bulkCreateEvents` (`POST https://www.wixapis.com/calendar/v3/bulk/events/create`) with one event per course session.
+4. For each event, set:
+   - `event.scheduleId` to the course service's `service.schedule.id`
+   - `event.type` to `COURSE`
+   - `event.resources` to at least one resource object using a valid `resourceId`
+   - start/end fields for the session time
+5. Query the service/calendar events afterward to confirm future events exist before saying the course is bookable.
+
+If the session details are missing, create only the service and clearly tell the user that the course still needs session events before it can be booked.
 
 ---
 
-## Step 4: Summary Message
+## Step 5: Summary Message
 
 Provide a summary including:
 
 1. **What was created** — service name, total course price, capacity
 2. **Assumptions made** — list defaults used (e.g., "I set the capacity to 10 participants since you didn't specify")
 3. **Pricing clarification** — note that the price is for the entire course, not per session
-4. **Schedule note** — remind the user that course sessions (dates and times) still need to be set up
-5. **Next steps** — "Click Save to finalize, then set up the course schedule"
+4. **Schedule status** — say whether course session events were created and verified; do not say the course is bookable if only the service exists
+5. **Next steps** — if events were not created, tell the user to provide session dates/times or set up the course schedule
 6. **Offer to adjust** — "Want me to change the price, capacity, or description?"
 
 **Example:**
@@ -178,7 +202,7 @@ Provide a summary including:
 >
 > I assumed a capacity of 10 since you didn't specify. The price of $300 covers the entire course — customers pay once for all sessions. You can review and adjust the details in the service form.
 >
-> **Next step:** You'll need to set up the course schedule (specific session dates and times) in the service form.
+> **Next step:** You'll need to set up the course schedule (specific session dates and times) before customers can book it.
 
 ---
 
@@ -187,6 +211,7 @@ Provide a summary including:
 | Error | Cause | Action |
 |---|---|---|
 | 400 "INVALID_PAYMENT_OPTIONS" | Payment misconfigured | Free: `inPerson: true`, `online: false`. Paid: price > 0 |
+| Course page says "Ended", "Beendet", or "This service is not available" after service creation | Service exists but no future course events were created on `service.schedule.id` | Create course events via Calendar Events `bulkCreateEvents`, then verify future events exist |
 | 403 | Permission denied | Inform user they lack permission |
 
 ---

package/skills/wix-manage/references/bookings/diagnose-availability-issues.md

@@ -1,32 +1,39 @@
 ---
-name: "Diagnose Bookings Availability Issues"
-description: "Diagnoses why an appointment-based Wix Bookings service has no bookable time slots or why customers can't book it. First rules out service-level blockers the availability endpoint can't see — the service being hidden from the site or having online booking turned off — then runs the DiagnoseAvailability endpoint for ordered, machine-readable staff/setup reasons, with a manual fallback for booking-policy and capacity causes. Use when a service shows no availability or customers can't book or find it."
+name: "Check Bookings Availability (and Diagnose Issues)"
+description: "Answers whether an appointment-based Wix Bookings service currently has bookable availability — the primary question — and diagnoses the cause only when there's no availability or the owner asks why. To diagnose, first rules out service-level blockers the availability endpoint can't see (service hidden, online booking off), then runs DiagnoseAvailability for ordered, machine-readable staff/setup reasons, with a manual fallback for booking-policy and capacity causes. Use when someone asks whether a service has availability, or why a service shows no times / customers can't book it."
 ---
-# Diagnose Bookings Availability Issues
+# Check Bookings Availability (and Diagnose Issues)
+
+This recipe answers two related questions, in order of how often they're asked:
+
+1. **"Does this service have availability right now?"** — the default. Give a short, plain status answer.
+2. **"Why is there no availability / why can't customers book?"** — diagnose the cause. Only do this when there's **no bookable availability**, or the owner **explicitly asks** why / how to fix it.
+
+Don't diagnose by default. If the owner just wants to know the status and the service is bookable, answer that and stop.
 
 > ## ⚠️ Output rule (read first)
-> You are talking to a **site owner**, not a developer. Use everything below — the endpoint, JSON, reason codes, `suggestedAction` values, field names — **only to run the diagnosis**. Your **reply to the user must be plain language**: the cause in everyday words plus the fix, and an offer to help.
+> You are talking to a **site owner**, not a developer. Use everything below — endpoints, JSON, reason codes, `suggestedAction` values, field names — **only to do the work.** Your **reply must be plain language**.
 >
-> **Never put any of these in your reply:** endpoint paths or curl, JSON, reason-code names (e.g. `RESOURCE_NOT_AVAILABLE_AT_SERVICE_LOCATION`), `suggestedAction` enums, or field names. Translate them. See [Presenting the diagnosis](#presenting-the-diagnosis-to-the-user).
+> **Keep it short and only say what's relevant:**
+> - When the service **is** bookable, confirm it in a sentence. **Don't recite everything that happens to be fine** — the owner didn't ask for an audit. ❌ "It's visible on your site (not hidden). Online booking is ON. It has 1 staff member assigned and 1 location." ✅ "Yes — **[service]** has open times customers can book."
+> - When you diagnose, surface **only the blocking cause and its fix** — not a checklist of everything that passed.
+>
+> **Never put any of these in your reply:** endpoint paths or curl, JSON, reason-code names (e.g. `RESOURCE_NOT_AVAILABLE_AT_SERVICE_LOCATION`), `suggestedAction` enums, or field names. Translate them. See [Presenting to the user](#presenting-to-the-user).
 >
 > ✅ "Your staff don't have working hours at the location this service is offered at, so there's nothing to book. Want me to add hours there?"
 > ❌ "`DiagnoseAvailability` returned `RESOURCE_NOT_AVAILABLE_AT_SERVICE_LOCATION` / `CHECK_WORK_LOCATIONS`."
 
 ## When to use
 
-A site owner reports that an **appointment-based** service has **no bookable time slots**, or that **customers can't book (or can't even find) the service**. This recipe finds the cause.
-
-Diagnosis runs in order — **cheapest, most common blockers first:**
-
-0. **Rule out service-level blockers.** Before touching availability, confirm the service is actually **visible** and **open to online booking**. A service that's hidden from the site, or has online booking turned off, can't be booked no matter how much staff availability exists — and `DiagnoseAvailability` does **not** check either. This is the single most common reason a customer "can't book" a service. See [Step 0](#step-0--rule-out-service-level-blockers-visibility--online-booking).
-1. **Call `DiagnoseAvailability`.** It returns ordered, machine-readable reason codes — each with a suggested owner action — for staff/resource setup and configuration problems. Fix what it reports and re-check.
-2. **Fall back to `ListAvailabilityTimeSlots`** only when the endpoint is inconclusive. The endpoint detects setup/configuration problems; it does **not** evaluate booking policy or remaining capacity, so those are checked here.
-
-> ### ⚠️ Don't skip Step 0
-> If the owner's complaint is "customers can't book / can't see this service" (as opposed to "the calendar is empty"), **Step 0 is very likely the answer.** Jumping straight to `DiagnoseAvailability` / `ListAvailabilityTimeSlots` on a hidden service will surface a real-but-irrelevant availability or policy detail (e.g. "too late to book") and give the owner the **wrong** diagnosis. Always confirm visibility and online booking first.
+- Owner asks whether an **appointment-based** service has availability / bookable times → [Step 1](#step-1--report-the-current-availability-status).
+- Owner reports the service has **no bookable times**, or that **customers can't book (or can't even find) it** → Step 1 will come back empty, so go on to diagnose ([Step 2](#step-2--rule-out-service-level-blockers-visibility--online-booking) onward). For "can't book / can't find," start diagnosis at Step 2 even if Step 1 returned slots — a hidden service still lists slots (see the note in Step 1).
+- Owner **narrows to a specific date/time** ("why nothing on 3 Aug from 4pm?") and the slot check for that window comes back **empty** → this **is** a "why" question. Run the diagnosis (Step 2 → [Step 3](#step-3--run-the-diagnosis)). **Do not answer it from the empty slot list alone.**
 
 > **Scope:** appointment-based services.
 
+> ## 🚫 Never invent the cause (read first)
+> An empty `ListAvailabilityTimeSlots` tells you **there is no availability — not *why*.** The reason for an empty result comes **only** from the checks in Steps 2–4 (`service.hidden` / `onlineBooking`, then `DiagnoseAvailability`, then policy/capacity). **Never state a cause you didn't get from them** — do not guess "the staff aren't scheduled," "it's outside working hours," a date-range problem, or anything else from a zero slot count. If you haven't run the diagnosis, you don't know the reason yet: run it, then report what it returns.
+
 ---
 
 ## Prerequisites
@@ -37,13 +44,37 @@ Diagnosis runs in order — **cheapest, most common blockers first:**
 
 - Typically the `serviceId` (optionally with a staff member's `resourceId` to scope to one provider). A `resourceId` on its own is also supported for the staff editor, where no service is in context — see [Which inputs to pass](#which-inputs-to-pass-prefer-a-service).
 
-- **Authorization:** the caller needs the `bookings:availability:v2:time_slot:diagnose_availability` permission. A plain site/owner token can come back **403 (empty body)** if that permission isn't granted to the caller — that's an auth problem, not "no cause found." Ensure the calling context carries the permission before treating a 403 as inconclusive.
+- **Authorization (diagnosis only):** to call `DiagnoseAvailability` the caller needs the `bookings:availability:v2:time_slot:diagnose_availability` permission. A plain site/owner token can come back **403 (empty body)** if that permission isn't granted — that's an auth problem, not "no cause found." Ensure the calling context carries the permission before treating a 403 as inconclusive.
 
 ---
 
-## Step 0 — Rule out service-level blockers (visibility & online booking)
+## Step 1 — Report the current availability status
+
+This is the default answer. Find out whether customers can actually book the service right now, then say so plainly.
+
+- **Endpoint:** `ListAvailabilityTimeSlots` — the same slots a customer sees. See [End-to-End Booking Flow](end-to-end-booking-flow.md) for the request shape. Query the service over a sensible upcoming window (e.g. the next few weeks) in the site's time zone.
+
+Interpret the result:
+
+| What comes back | Availability status | What to do |
+|-----------------|---------------------|------------|
+| One or more **bookable** slots | **Bookable.** | Tell the owner in a sentence and stop — no diagnosis needed unless they ask why/how to change something. |
+| Slots exist but **none are bookable** (`nonBookableReasons` / `bookingPolicyViolations` set) | **Not bookable — policy/capacity.** | This is the cause. Surface it directly ([policy/capacity causes](#booking-policy--capacity-slots-exist-but-arent-bookable)). No need to run `DiagnoseAvailability`. |
+| **No slots at all** | **No availability.** | Diagnose: go to [Step 2](#step-2--rule-out-service-level-blockers-visibility--online-booking), then [Step 3](#step-3--run-the-diagnosis). **Don't guess the reason from the empty list** — an empty result isn't a cause. |
+
+> **The hidden-service trap.** A service that's **hidden** from the site, or has **online booking turned off**, can still list slots here — so bookable slots do **not** prove customers can book it. When the complaint is "customers can't book / can't find this service" (as opposed to "the calendar is empty"), **run [Step 2](#step-2--rule-out-service-level-blockers-visibility--online-booking) before trusting the slot count** — it's the single most common cause and neither `ListAvailabilityTimeSlots` nor `DiagnoseAvailability` detects it.
+
+If **no slots come back at all**, also sanity-check the inputs before concluding "no availability": the queried window isn't entirely in the past, and any `locations` filter is actually offered by the service.
+
+---
+
+## Diagnosis
+
+Do the following **only** when Step 1 found no availability, or the owner asks why there are no times / how to fix it / why customers can't book. Run the checks in order — cheapest, most common blockers first.
+
+## Step 2 — Rule out service-level blockers (visibility & online booking)
 
-Two service settings block booking **entirely**, regardless of staff availability, and are invisible to `DiagnoseAvailability` and `ListAvailabilityTimeSlots`. Check them **first** with a single read of the service.
+Two service settings block booking **entirely**, regardless of staff availability, and are invisible to `DiagnoseAvailability`. Check them **first** with a single read of the service.
 
 - **Endpoint:** `GET https://www.wixapis.com/_api/bookings/v2/services/{serviceId}`
 
@@ -54,20 +85,20 @@ Inspect two fields on the returned `service`:
 | `hidden` | `true` | The service is **hidden from the site and app**. Customers can't see or book it. In the dashboard this is the **"Visible on your site and app"** toggle turned **off**. |
 | `onlineBooking.enabled` | `false` | **Online booking is turned off** for this service. It may be visible, but customers can't book it online (staff can still book it manually). |
 
-- If **`hidden: true`** → that's the cause. Stop here; don't run the availability diagnosis. Fix: make the service visible (offer to flip the toggle for them).
+- If **`hidden: true`** → that's the cause. Stop here. Fix: make the service visible (offer to flip the toggle for them).
 - If **`onlineBooking.enabled: false`** → that's the cause (for "can't book online"). Fix: turn online booking on.
-- If both are fine (`hidden: false`, `onlineBooking.enabled: true`) → proceed to Step 1.
+- If both are fine (`hidden: false`, `onlineBooking.enabled: true`) → proceed to Step 3. **Don't announce that they're fine** — just move on.
 
-> **Why this comes first:** a hidden service can still have staff, working hours, and internally-generated time slots — so the availability endpoint and `ListAvailabilityTimeSlots` will happily report on those slots (including policy details like "too late to book"). None of that is the real reason the customer can't book. Confirming visibility first prevents a confidently-wrong answer.
+> **Why this comes first:** a hidden service can still have staff, working hours, and internally-generated time slots — so `ListAvailabilityTimeSlots` and `DiagnoseAvailability` will happily report on those slots (including policy details like "too late to book"). None of that is the real reason the customer can't book. Confirming visibility first prevents a confidently-wrong answer.
 
 ---
 
-## Step 1 — Run the diagnosis
+## Step 3 — Run the diagnosis
 
 `DiagnoseAvailability` is a read-only custom action that explains **why availability is empty** rather than returning slots.
 
 - **Endpoint:** `POST https://www.wixapis.com/_api/service-availability/v2/time-slots/diagnose`
-- **Maturity:** ALPHA, behind the `diagnoseAvailabilityEndpoint` feature toggle (deployed and available in production). If it returns **no reasons** for a service you'd expect to be broken, treat the result as inconclusive and go to Step 2.
+- **Maturity:** ALPHA, behind the `diagnoseAvailabilityEndpoint` feature toggle (deployed and available in production). If it returns **no reasons** for a service you'd expect to be broken, treat the result as inconclusive and go to [Step 4](#step-4--fallback-when-the-endpoint-is-inconclusive).
 - **`hasAvailability`** is set `true` only on the **service paths**, when the availability-window check confirms real availability — and for `serviceId`-only, only when the service needs a single staff resource type. It is **never** asserted `true` for `serviceId`+`resourceId` (one resource can't confirm the whole service) or for resource-only. So `hasAvailability: false` with an empty `reasons` array means **inconclusive** ("no blocking cause found"), not necessarily "no availability."
 
 ### Which inputs to pass (prefer a service)
@@ -134,11 +165,11 @@ curl -X POST 'https://www.wixapis.com/_api/service-availability/v2/time-slots/di
 
 - `reasons` are ordered **most-specific first**. Fix the first, then re-run.
 - `resolvedContext` echoes the inputs actually used (resolved locations, duration, buffer, window, time zone) — use it to confirm you diagnosed what you meant to.
-- Empty `reasons` ⇒ **inconclusive** → go to **Step 2**.
+- Empty `reasons` ⇒ **inconclusive** → go to **Step 4**.
 
 ### Reason codes → owner fix (agent-internal — never shown to the user)
 
-> This table is for **your** interpretation only. Map the returned code to the plain-language cause and fix, then write the reply in everyday words — the code names and `suggestedAction` values must not appear in your response. See [Presenting the diagnosis](#presenting-the-diagnosis-to-the-user).
+> This table is for **your** interpretation only. Map the returned code to the plain-language cause and fix, then write the reply in everyday words — the code names and `suggestedAction` values must not appear in your response. See [Presenting to the user](#presenting-to-the-user).
 
 | `code` | `suggestedAction` | Meaning & fix |
 |--------|-------------------|---------------|
@@ -147,6 +178,7 @@ curl -X POST 'https://www.wixapis.com/_api/service-availability/v2/time-slots/di
 | `RESOURCE_HAS_NO_WORKING_HOURS` | `CHECK_STAFF_WORKING_HOURS` | The staff member has no working-hours schedule. Configure working hours — see [Bookings Staff Setup](bookings-staff-setup.md). |
 | `RESOURCE_NOT_AVAILABLE_AT_SERVICE_LOCATION` | `CHECK_WORK_LOCATIONS` | Assigned resources have availability windows, but none at a location the service offers. Add working hours at an offered location, offer the service where the staff works, or assign a provider who works at the offered location. |
 | `NO_RESOURCE_AVAILABILITY_WINDOWS` | `CHECK_STAFF_WORKING_HOURS` | No availability windows exist anywhere in the diagnosed range. Add working hours, or widen the range. |
+| `REQUESTED_DATE_OUTSIDE_SERVICE_AVAILABILITY_RANGE` | `CHECK_SERVICE_AVAILABILITY_RANGE` | The dates being checked fall **outside the date range the service itself is offered on** (its own availability window) — so no slots exist there, whatever the staff's hours. Covers both *before* the range starts and *after* it ends. Deterministic: returned on the **standard call** (no `deep` needed) and **ahead of** the working-hours/blocked reasons, so trust it over `RESOURCE_NOT_IN_WORKING_HOURS`. Fix: extend the service's available date range, or check dates within it. (The exact bounds aren't in `resolvedContext`; if you need to state the start date, read `service.schedule.firstSessionStart` via [Services V2 Get Service](#step-2--rule-out-service-level-blockers-visibility--online-booking).) |
 | `REQUESTED_LOCATION_NOT_OFFERED_BY_SERVICE` | `CHECK_SERVICE_LOCATIONS` | A requested `locations` filter isn't offered by the service. Drop the filter or fix the service's locations. |
 | `DURATION_TOO_LONG_FOR_AVAILABLE_WINDOWS` | `REDUCE_DURATION_OR_BUFFER` | The service is longer than every free window. Shorten it or lengthen working hours. |
 | `BUFFER_TIME_ELIMINATES_WINDOWS` | `REDUCE_DURATION_OR_BUFFER` | Buffer time consumes all otherwise-free windows. Reduce the buffer or lengthen working hours. |
@@ -176,10 +208,11 @@ curl -X POST 'https://www.wixapis.com/_api/service-availability/v2/time-slots/di
 
 ---
 
-## Step 2 — Fallback when the endpoint is inconclusive
+## Step 4 — Fallback when the endpoint is inconclusive
 
-Empty `reasons` + still no bookable slots usually means the cause is one the endpoint **doesn't evaluate**: booking policy or remaining capacity. Call `ListAvailabilityTimeSlots` for the same service and window, and inspect the returned slots:
+Empty `reasons` + still no bookable slots usually means the cause is one `DiagnoseAvailability` **doesn't evaluate**: booking policy or remaining capacity. You may already have this from the `ListAvailabilityTimeSlots` call in Step 1 — if not, call it again for the same service and window and inspect the returned slots.
 
+<a id="booking-policy--capacity-slots-exist-but-arent-bookable"></a>
 - **`nonBookableReasons`** — `noRemainingCapacity`, `violatesBookingPolicy`, `reservedForWaitingList`, `eventCancelled`.
 - **`bookingPolicyViolations`** — `tooEarlyToBook`, `tooLateToBook`, `bookOnlineDisabled`.
 
@@ -189,20 +222,23 @@ See [End-to-End Booking Flow](end-to-end-booking-flow.md) for the `ListAvailabil
 
 ---
 
-## Presenting the diagnosis to the user
+## Presenting to the user
 
-The diagnosis is part of a conversation with a site owner. Reply in plain, friendly language:
+Whether you're reporting status or a cause, reply in plain, friendly language and keep it short.
 
-- **Don't expose the internals** — no reason codes, `suggestedAction` enums, raw JSON, endpoint names, or field paths.
-- **Lead with the cause in plain English**, then give the concrete fix as the next step. One or two short sentences is usually enough.
+- **Answer the actual question.** If they asked "is it available," the reply is a status line — not a diagnosis. Only explain causes when there's no availability or they asked why.
+- **Only say what's relevant.** When the service is bookable, confirm it in a sentence; **don't list every setting that's fine** ("visible, online booking on, 1 staff, 1 location" — the owner didn't ask). When diagnosing, give **only the blocking cause and its fix**, not a rundown of everything that passed.
+- **Don't expose internals** — no reason codes, `suggestedAction` enums, raw JSON, endpoint names, or field paths.
+- **Lead with the point in plain English**, then the concrete next step. One or two short sentences is usually enough.
 - **Use the owner's own terms** — "your service", "your staff", "the dates you're looking at", real location names from `resolvedLocations`.
 - **Offer to help with the fix** rather than only stating it.
-- If the result is inconclusive (empty `reasons`), say only that you **couldn't find a blocking problem**, and describe what you'll check next (policy/capacity, or re-run against a service for a resource-only check). **Do not state or imply that anything is set up correctly** — an empty `reasons` array means "no blocker detected," *not* "working hours / locations / setup are present." In particular, on the resource-only path never say the staff "have working hours set"; the check doesn't verify that. Don't imply the service is fine.
+- If diagnosis is **inconclusive** (empty `reasons`), say only that you **couldn't find a blocking problem**, and describe what you'll check next (policy/capacity, or re-run against a service for a resource-only check). **Do not state or imply that anything is set up correctly** — an empty `reasons` array means "no blocker detected," *not* "working hours / locations / setup are present." On the resource-only path never say the staff "have working hours set"; the check doesn't verify that.
 
-**Plain-language phrasing per cause:**
+**Plain-language phrasing per outcome:**
 
-| Cause | Say something like |
-|-------|--------------------|
+| Outcome | Say something like |
+|---------|--------------------|
+| Service **is** bookable (status) | "Yes — **[service]** has open times customers can book (the next one is [day/time])." |
 | Service is hidden from the site (`hidden: true`) | "This service is currently hidden from your site and app, so customers can't see or book it. Want me to make it visible?" |
 | Online booking turned off (`onlineBooking.enabled: false`) | "Online booking is turned off for this service, so customers can't book it themselves online (you can still book it for them manually). Want me to turn online booking on?" |
 | No staff/resources on the service | "This service doesn't have any staff assigned yet, so there's nothing to book. Want me to help you add someone?" |
@@ -210,11 +246,12 @@ The diagnosis is part of a conversation with a site owner. Reply in plain, frien
 | Provider has no working hours | "The staff for this service don't have any working hours set, so there are no times to offer. Let's set their hours." |
 | Provider works only at other locations | "Your staff have working hours, but not at the location(s) this service is offered at. We can either add hours at one of the service's locations, or offer the service where they already work." |
 | No working-hours windows in range | "None of the staff for this service have working hours in the dates you're checking. Let's add or extend their hours — or try a different date range." |
+| Dates outside the service's available range | "This service isn't offered on the dates you're looking at — it's only available during a set date range. Want me to extend the dates it's offered, or check a date inside that range?" |
 | Outside working hours (deep) | "For those dates, your staff simply aren't scheduled to work, so there's nothing to offer. Let's add working hours in that period." |
 | Within hours but blocked/busy (deep) | "Your staff are scheduled to work then, but that time is already taken up — by existing bookings or events on their calendar. Freeing some of it up will open slots." |
 | Service too long / buffer too large | "The service is longer than any open gap in your staff's schedule (the duration plus buffer doesn't fit). Shortening it a bit, or widening working hours, would open up slots." |
 | Requested location not offered | "This service isn't offered at the location you picked. Want me to add that location to the service, or check a different one?" |
-| Slots exist but aren't bookable (Step 2) | "There are times available, but customers can't book them right now — [e.g. they're fully booked / it's too early or late to book per your policy]. Here's how to adjust that." |
+| Slots exist but aren't bookable | "There are times available, but customers can't book them right now — [e.g. they're fully booked / it's too early or late to book per your policy]. Here's how to adjust that." |
 
 **Example conversational reply** (for a location-mismatch result):
 
@@ -230,29 +267,35 @@ Popular reasons a service shows no availability, and where each surfaces:
 
 | Situation | Where it surfaces | Fix |
 |-----------|-------------------|-----|
-| Service hidden from the site/app | Step 0 — `service.hidden: true` | Make the service visible ("Visible on your site and app" toggle). |
-| Online booking turned off | Step 0 — `service.onlineBooking.enabled: false` | Turn online booking on for the service. |
+| Service **is** bookable | Step 1 — `ListAvailabilityTimeSlots` returns bookable slots | Nothing — report the status. |
+| Service hidden from the site/app | Step 2 — `service.hidden: true` | Make the service visible ("Visible on your site and app" toggle). |
+| Online booking turned off | Step 2 — `service.onlineBooking.enabled: false` | Turn online booking on for the service. |
 | No staff/resources on the service | `NO_ASSIGNED_STAFF_OR_RESOURCES` | Assign staff/resources. |
 | Provider isn't on the service | `RESOURCE_NOT_ASSIGNED_TO_SERVICE` | Assign the provider. |
 | Provider has no working hours | `RESOURCE_HAS_NO_WORKING_HOURS` | Configure working hours. |
 | Provider works only at other locations | `RESOURCE_NOT_AVAILABLE_AT_SERVICE_LOCATION` | Align staff work locations with the service's offered locations. |
 | No working-hours windows in range | `NO_RESOURCE_AVAILABILITY_WINDOWS` | Add working hours / widen the range. |
+| Dates fall outside the service's own offered date range | `REQUESTED_DATE_OUTSIDE_SERVICE_AVAILABILITY_RANGE` | Extend the service's available date range, or check dates within it. |
 | No windows — outside working hours (deep) | `RESOURCE_NOT_IN_WORKING_HOURS` (`deep: true`) | Add or extend working hours in the range. |
 | No windows — within hours but blocked/busy (deep) | `RESOURCE_BLOCKED` (`deep: true`) | Free up blocked time / check the external calendar. |
 | Service too long / buffer too large for the windows | `DURATION_TOO_LONG_FOR_AVAILABLE_WINDOWS`, `BUFFER_TIME_ELIMINATES_WINDOWS` | Shorten duration/buffer or lengthen hours. |
 | Requested location not offered | `REQUESTED_LOCATION_NOT_OFFERED_BY_SERVICE` | Fix the location filter or the service's locations. |
-| Slots exist but aren't bookable (fully booked, too early/late, online booking off) | Step 2 — `ListAvailabilityTimeSlots` `nonBookableReasons` / `bookingPolicyViolations` | Adjust capacity or booking policy. |
+| Slots exist but aren't bookable (fully booked, too early/late, online booking off) | Step 1 / Step 4 — `ListAvailabilityTimeSlots` `nonBookableReasons` / `bookingPolicyViolations` | Adjust capacity or booking policy. |
 
 ---
 
 ## Gotchas
 
-- **A hidden service is the classic wrong-diagnosis trap.** `hidden: true` (or `onlineBooking.enabled: false`) blocks booking entirely, but a hidden service can still have staff and internally-generated slots — so `DiagnoseAvailability` and `ListAvailabilityTimeSlots` will report on those slots and their policy details (e.g. "too late to book"), none of which is the real reason. **Always run Step 0 first**, especially when the complaint is "customers can't book / can't see this service."
+- **Don't diagnose when you weren't asked to.** The default question is "does this have availability" — answer the status and stop. Only dig into causes when there's no availability or the owner asks why / how to fix.
+- **Keep the reply to what's relevant.** When a service is bookable, don't recite every setting that's fine; when diagnosing, give only the blocking cause, not a pass/fail checklist.
+- **A hidden service is the classic wrong-diagnosis trap.** `hidden: true` (or `onlineBooking.enabled: false`) blocks booking entirely, but a hidden service can still list slots — so `ListAvailabilityTimeSlots` and `DiagnoseAvailability` will report on those slots and their policy details (e.g. "too late to book"), none of which is the real reason. When the complaint is "customers can't book / can't see this service," **run Step 2 first.**
 - **`hasAvailability: false` + empty `reasons` ≠ a confirmed problem.** It means "no blocking cause detected." Always confirm with `ListAvailabilityTimeSlots`.
-- **The endpoint is ALPHA and feature-toggled.** If it returns nothing for an obviously broken service, the `diagnoseAvailabilityEndpoint` toggle may be off — fall back to Step 2.
+- **`DiagnoseAvailability` is ALPHA and feature-toggled.** If it returns nothing for an obviously broken service, the `diagnoseAvailabilityEndpoint` toggle may be off — fall back to Step 4.
 - **A 403 is an auth problem, not a diagnosis.** The action needs the `bookings:availability:v2:time_slot:diagnose_availability` permission; a caller without it gets a 403 with an empty body. Don't read that as "no cause found" — confirm the caller has the permission (see [Prerequisites](#prerequisites)).
+- **Never state a cause you didn't diagnose.** A zero slot count from `ListAvailabilityTimeSlots` means "no availability," not a reason. Guessing "the staff aren't scheduled to work" (or any other cause) from an empty list is the failure this recipe exists to prevent — run `DiagnoseAvailability` and report the code it returns. This applies especially when the owner narrows to a specific date/time and it comes back empty: that's a diagnosis trigger, not a status reply.
+- **A date-range restriction is a distinct cause — don't blame staff hours for it.** When a service is only offered within a set date range and the owner asks about a date outside it, `DiagnoseAvailability` returns `REQUESTED_DATE_OUTSIDE_SERVICE_AVAILABILITY_RANGE` on the **standard call**, ahead of the deep working-hours/blocked reasons. If you see it, say the service isn't offered on those dates — **not** that staff aren't scheduled (they may well work then; the service just isn't offered). It covers dates both before and after the range.
 - **`deep: true` needs a `serviceId`** (resource-only + `deep` → `MISSING_ARGUMENTS`) and only refines a "no windows" result — it does nothing when windows already exist.
-- **The endpoint ignores booking policy and capacity** — those are Step 2.
+- **`DiagnoseAvailability` ignores booking policy and capacity** — those come from `ListAvailabilityTimeSlots` (Step 1 / Step 4).
 - **Resource-only diagnosis is lighter.** Passing `resourceId` without `serviceId` catches missing/empty working hours but skips the window, location, and deep checks, so it can return "inconclusive" for service-dependent problems. Valid when there's no service context (e.g. the staff editor); otherwise pair the resource with a service.
 - **Appointment-based services only.**
 

package/skills/wix-manage/references/cms/cms-dashboard-navigation.md

@@ -0,0 +1,44 @@
+---
+name: "CMS Dashboard Navigation"
+description: "Builds direct links to the Wix CMS (Content Manager) dashboard pages on manage.wix.com — the collections list and a specific collection's items view. Pairs collections and data items with their read APIs so you can fetch data and hand back a 'view it in your dashboard' link. Use when the user asks where something is in the Wix dashboard, wants a direct link to a dashboard page, or you need a dashboard URL to include with the result of an API operation."
+---
+
+# CMS Dashboard Navigation
+
+Build direct links into the CMS (Content Manager) pages of a site's dashboard. For the general URL contract (metaSiteId, fallbacks, redirects), see [Dashboard Navigation](../dashboard-navigation/dashboard-navigation.md).
+
+All CMS (app ID `e593b0bd-b783-45b8-97c2-873d42aacaf4`) pages live under:
+
+```
+https://manage.wix.com/dashboard/{metaSiteId}/wix-cms/{route}
+```
+
+## Main Pages
+
+| Page | URL after `/dashboard/{metaSiteId}/` | What it manages |
+|---|---|---|
+| Collections list | `wix-cms` | All CMS collections on the site |
+| Collection items | `wix-cms/data/{collectionId}` | A specific collection's items table |
+
+Older links (`database`, `developer-tools/database`) redirect to `wix-cms`. `{collectionId}` is the collection's ID (e.g. `Stores/Products` for app collections, or the ID you set when creating the collection).
+
+## Pairing Entities with Their Read APIs
+
+Fetch the entity via REST, then link the matching dashboard page. All calls use `https://www.wixapis.com` with an `Authorization` header.
+
+| Entity | Read API | Dashboard link |
+|---|---|---|
+| Collection (schema) | `GET /wix-data/v2/collections/{collectionId}` · `GET /wix-data/v2/collections` (list) | `wix-cms/data/{collectionId}` |
+| Data item | `POST /wix-data/v2/items/query` (body includes `dataCollectionId`) · `GET /wix-data/v2/items/{itemId}?dataCollectionId=...` | `wix-cms/data/{collectionId}` (the collection's items table) |
+
+Example — after creating a collection and inserting items:
+
+```
+Created the "Recipes" collection with 12 items.
+Manage it here: https://manage.wix.com/dashboard/{metaSiteId}/wix-cms/data/Recipes
+```
+
+## Notes
+
+- There is no per-item dashboard URL; link the collection's items table.
+- Unknown deeper paths fall back to the longest matching route, so a wrong collection ID lands on the CMS home rather than a 404.