@wix/agent-skills 1.5.0 → 1.7.0

package/skills/wix-app/references/SERVICE_PLUGIN.md

@@ -1,27 +1,28 @@
 
 # Wix Service Plugin (SPI) Builder
 
-Creates service plugin extensions for Wix CLI applications. Service plugins are a set of APIs defined by Wix that you can use to inject custom logic into the existing backend flows of Wix business solutions or to introduce entirely new flows to Wix sites.
+Service plugins are a set of APIs defined by Wix that let you inject custom logic into the existing backend flows of Wix business solutions or introduce entirely new flows. When you implement a service plugin, Wix calls your custom functions during specific flows. Common use cases include eCommerce customization (shipping, fees, payment settings, validations) and Bookings customization (staff sorting).
 
-When you implement a service plugin, Wix calls your custom functions during specific flows. Common use cases include eCommerce customization (shipping, fees, payment settings, validations) and Bookings customization (staff sorting), but service plugins can extend any Wix business solution that exposes SPIs.
+## Scaffold
 
-## Quick Start Checklist
+Use `wix generate --params` with `extensionType: SERVICE_PLUGIN`. `pluginType` is one of:
 
-Follow these steps in order when creating a service plugin:
+| Value | SPI |
+| --- | --- |
+| `ECOM_ADDITIONAL_FEES` | Additional Fees |
+| `ECOM_SHIPPING_RATES` | Shipping Rates |
+| `ECOM_DISCOUNTS_TRIGGER` | Discount Triggers |
+| `ECOM_VALIDATIONS` | Validations |
+| `ECOM_PAYMENT_SETTINGS` | Payment Settings |
+| `GIFT_CARDS_PROVIDER` | Gift Cards Provider |
+| `STAFF_SORTING_PROVIDER` | Bookings Staff Sorting |
+| `REALTIME_PERMISSIONS_PROVIDER` | Realtime Permissions Provider |
 
-1. [ ] **Read the reference doc** for your SPI type, then **STOP and call `ReadFullDocsMethodSchema`** with the docs URL from the reference to get the exact request/response types — **DO NOT write any code until you have the schema**
-2. [ ] Create plugin folder: `src/extensions/backend/service-plugins/<service-type>/<plugin-name>/`
-3. [ ] Create `plugin.ts` with correct imports and `provideHandlers()` call
-4. [ ] Implement all required handler functions with complete business logic
-5. [ ] Create `extensions.ts` with appropriate builder method and unique UUID
-6. [ ] Update `src/extensions.ts` to import and use the new extension
-7. [ ] Run `npx tsc --noEmit` to verify TypeScript compiles
-8. [ ] Run `npx wix build` to verify build succeeds
-9. [ ] Test by triggering the relevant site action (e.g., add to cart for fees)
+`name` must be lowercase alphanumeric + hyphens, max 19 characters. The CLI generates the folder, `plugin.ts`, the builder file, the UUID, and the `src/extensions.ts` registration with the appropriate builder method for the SPI type. Some SPI types (e.g., `ECOM_SHIPPING_RATES`) get a `description` placeholder field in the generated builder — replace it with your real copy.
 
 ## References
 
-**You MUST read the relevant reference document before implementing a relevant SPI.** Each reference contains the correct imports, handler signatures, response structures, and working examples.
+**You MUST read the relevant reference document before implementing an SPI**, and **call `ReadFullDocsMethodSchema`** with the docs URL it points at to get the exact request/response types — **do NOT edit code until you have the schema**. If the schema alone isn't enough, follow up with `ReadFullDocsArticle` on the same URL for prose explanations and additional code examples. Each reference also contains the correct imports, handler signatures, response structures, and a worked example.
 
 | SPI Type | Reference |
 | --- | --- |
@@ -33,199 +34,45 @@ Follow these steps in order when creating a service plugin:
 | Validations | [VALIDATIONS.md](service-plugin/VALIDATIONS.md) |
 | Bookings Staff Sorting | [BOOKINGS-STAFF-SORTING.md](service-plugin/BOOKINGS-STAFF-SORTING.md) |
 
-## Output Structure
-
-Service plugins consist of two files that work together. Registration of plugins requires an extension builder file.
-
-```
-src/extensions/backend/service-plugins/
-└── {service-type}/
-    └── {plugin-name}/
-        ├── plugin.ts           # Handler logic with provideHandlers()
-        └── extensions.ts       # Builder configuration (id, name, source)
-```
-
-### File Descriptions
-
-| File | Purpose |
-| --- | --- |
-| `plugin.ts` | Contains the service plugin handler logic with `provideHandlers()` - this is where you implement your custom business logic |
-| `extensions.ts` | Contains the service plugin builder configuration with id (GUID), name, source path, and builder-specific optional fields |
-
-## Implementation Requirements
-
-### Generation Requirements
-
-1. **Implement ALL required handler functions** with complete business logic
-2. **Include proper TypeScript types and error handling**
-3. **Focus on implementing the EXACT business logic** described in the user prompt
-
-### Implementation Patterns
-
-- **If capabilities are undocumented/unavailable**, explicitly state the gap and proceed only with documented minimal logic
-- **Implement all required handler functions** according to Wix specifications
-- **Never use placeholders** - always implement complete, working functionality
-
-### Data Validation
-
-All service plugins must include comprehensive data validation:
-
-- **Validate all input data** from Wix requests
-- **Ensure required fields** are present and properly formatted
-- **Handle missing or malformed data** gracefully
-- **Validate business logic constraints** (e.g., minimum order amounts, valid addresses)
-
 ## Implementation Pattern
 
-The handler file (`plugin.ts`) contains the service plugin logic. It must:
-
-1. Import the relevant service plugin from the appropriate package (e.g., `@wix/ecom/service-plugins` for eCommerce, `@wix/bookings/service-plugins` for Bookings)
-2. Call `provideHandlers()` with an object containing handler functions
-3. Each handler function receives a payload with `request` and `metadata`
-4. Return the expected response structure for that SPI type
+The scaffolded `plugin.ts` imports the relevant module from the SPI's package (`@wix/ecom/service-plugins`, `@wix/bookings/service-plugins`, etc.) and calls `provideHandlers({...})`. Each handler is invoked by Wix on the relevant flow with a `{ request, metadata }` payload and must return the SPI-specific response shape — see the per-SPI reference (Shipping Rates, Validations, etc.) for the exact request/response types and a worked example.
 
-```typescript
-import { shippingRates } from "@wix/ecom/service-plugins";
-
-shippingRates.provideHandlers({
-  getShippingRates: async (payload) => {
-    const { request, metadata } = payload;
-
-    // Implement custom logic based on request data
-    // - request contains cart items, shipping address, etc.
-    // - metadata contains currency, locale, etc.
-
-    return {
-      shippingRates: [
-        {
-          code: "custom-shipping",
-          title: "Custom Shipping",
-          logistics: {
-            deliveryTime: "3-5 business days",
-          },
-          cost: {
-            price: "9.99",
-            currency: metadata.currency || "USD",
-          },
-        },
-      ],
-    };
-  },
-});
-```
+## Implementation Requirements
 
-Handler functions are called automatically by Wix when the relevant site action triggers them. Your custom logic should be placed inside each handler function.
+- Implement ALL required handler functions for the chosen SPI with complete business logic. Focus on the EXACT business logic the user asked for.
+- Validate inputs: required fields present, correctly formatted, business constraints met (minimum order amounts, valid addresses, etc.). Handle missing or malformed data gracefully.
+- Return the exact response shape documented for the SPI; handler responses must match Wix's documented structure.
+- Handle errors gracefully — return appropriate error responses, don't throw unhandled exceptions.
+- Test edge cases (empty carts, missing addresses, invalid data) before reporting completion.
+- If a required capability isn't documented or available in the SDK, surface the gap to the user explicitly — do not fabricate.
 
 ## Elevating Permissions for API Calls
 
-When making Wix API calls from service plugins, you must elevate permissions using `auth.elevate` from `@wix/essentials`.
+When making Wix API calls from service plugins, wrap the SDK method with `auth.elevate` from `@wix/essentials` before calling it. The pattern is identical for every Wix SDK module (`@wix/data`, `@wix/ecom`, `@wix/stores`, etc.):
 
 ```typescript
 import { auth } from "@wix/essentials";
 import { items } from "@wix/data";
 
-export const myFunction = async () => {
-  const elevatedFunction = auth.elevate(items.query);
-  const elevatedResponse = await elevatedFunction("myCollection");
-  return elevatedResponse;
-};
+const elevated = auth.elevate(items.query);
+const response = await elevated("myCollection");
 ```
 
-```typescript
-import { auth } from "@wix/essentials";
-import { cart } from "@wix/ecom";
+## Builder field overrides
 
-export const myFunction = async () => {
-  const elevatedFunction = auth.elevate(cart.getCart);
-  const elevatedResponse = await elevatedFunction("cart-id");
-  return elevatedResponse;
-};
-```
+The CLI generates a builder with `id`, `name`, and `source`. Some SPI types accept additional optional fields you may want to set in the generated builder file:
 
-```typescript
-import { auth } from "@wix/essentials";
-import { products } from "@wix/stores";
-
-export const myFunction = async () => {
-  const elevatedFunction = auth.elevate(products.deleteCollection);
-  const elevatedResponse = await elevatedFunction("collection-id");
-  return elevatedResponse;
-};
-```
-
-## Best Practices
-
-### Development Workflow
-
-- **Always implement complete, working functionality** - never use placeholders
-- **Handle all required fields** according to Wix documentation
-- **Implement proper validation** for all input data
-- **Return responses in exact format** expected by Wix
-- **Add comprehensive error handling** for all failure scenarios
-- **Use meaningful variable names** and clear code structure
-- **Test thoroughly** with different input combinations
-
-### Implementation Guidelines
-
-- **Validate all input:** Check required fields are present and properly formatted
-- **Handle errors gracefully:** Return appropriate error responses, don't throw unhandled exceptions
-- **Return exact format:** Responses must match Wix documented structure exactly
-- **Use TypeScript types:** Leverage SDK types for better type safety
-- **Test edge cases:** Empty carts, missing addresses, invalid data
-- **Performance:** Keep calculations efficient - these run on every checkout
-- **Logging:** Add console.log for debugging but keep production logs minimal
-
-## Extension Registration
-
-**Extension registration is MANDATORY and has TWO required steps.**
-
-### Step 1: Create Plugin-Specific Extension File
-
-Each service plugin requires an `extensions.ts` file in its folder with the appropriate builder method for the SPI type:
-
-```typescript
-import { extensions } from "@wix/astro/builders";
-
-export const ecomadditionalfeesMyFees = extensions.ecomAdditionalFees({
-  id: "{{GENERATE_UUID}}",
-  name: "My Additional Fees",
-  source: "./extensions/backend/service-plugins/ecom-additional-fees/my-fees/plugin.ts",
-});
-```
-
-**CRITICAL: UUID Generation**
-
-The `id` must be a unique, static UUID v4 string. Generate a fresh UUID for each extension - do NOT use `randomUUID()` or copy UUIDs from examples. Replace `{{GENERATE_UUID}}` with a freshly generated UUID like `"a1b2c3d4-e5f6-7890-abcd-ef1234567890"`.
-
-### Builder Configuration Fields
-
-All builder methods accept these three fields:
-
-| Field | Type | Description |
+| SPI Type | Builder Method | Additional Optional Fields |
 | --- | --- | --- |
-| `id` | string | Service plugin ID as a GUID. Must be unique across all extensions in the project. |
-| `name` | string | The service plugin name (visible in app dashboard when developing an app). |
-| `source` | string | Path to the service plugin handler file that contains the plugin logic. |
-
-**Builder methods by SPI type and their accepted fields:**
-
-| SPI Type          | Builder Method           | Accepted Fields |
-| ----------------- | ------------------------ | --------------- |
-| Shipping Rates    | `ecomShippingRates()`    | `id`, `name`, `source`, `description`, `learnMoreUrl`, `dashboardUrl`, `fallbackDefinitionMandatory`, `thumbnailUrl` |
-| Additional Fees   | `ecomAdditionalFees()`   | `id`, `name`, `source` |
-| Validations       | `ecomValidations()`      | `id`, `name`, `source`, `validateInCart` |
-| Discount Triggers | `ecomDiscountTriggers()` | `id`, `name`, `source` |
-| Gift Cards        | `ecomGiftCards()`        | `id`, `name`, `source` |
-| Payment Settings  | `ecomPaymentSettings()`  | `id`, `name`, `source`, `fallbackValueForRequires3dSecure` |
-| Bookings Staff Sorting | `bookingsStaffSortingProvider()` | `id`, `name`, `source`, `methodName`, `methodDescription` (max 100 chars), `dashboardPluginId` |
-
-Only `ecomShippingRates()` accepts `description`. Passing unsupported fields to other builders causes TypeScript errors. `bookingsStaffSortingProvider()` requires `methodName` and `methodDescription` fields (methodDescription has a 100-character limit), and optionally accepts `dashboardPluginId`.
-
-### Step 2: Register in Main Extensions File
+| Shipping Rates | `ecomShippingRates()` | `description`, `learnMoreUrl`, `dashboardUrl`, `fallbackDefinitionMandatory`, `thumbnailUrl` |
+| Validations | `ecomValidations()` | `validateInCart` |
+| Payment Settings | `ecomPaymentSettings()` | `fallbackValueForRequires3dSecure` |
+| Bookings Staff Sorting | `bookingsStaffSortingProvider()` | `methodName` (required), `methodDescription` (required, max 100 chars), `dashboardPluginId` |
 
-**CRITICAL:** After creating the plugin-specific extension file, you MUST read [Extension Registration reference](EXTENSION_REGISTRATION.md) and follow the "App Registration" section to update `src/extensions.ts`.
+Only `ecomShippingRates()` accepts `description`. Passing unsupported fields to other builders causes TypeScript errors. `bookingsStaffSortingProvider()` requires `methodName` and `methodDescription` fields — set these in the generated builder file after scaffolding.
 
-**Without completing Step 2, the service plugin will not be active in the eCommerce system.**
+> **Performance:** keep handler logic efficient. Most SPIs run on hot paths (every cart view, every checkout step, etc.).
 
 ## Testing Service Plugins
 

package/skills/wix-app/references/SITE_PLUGIN.md

@@ -1,23 +1,15 @@
 
 # Wix Site Plugin Builder
 
-Creates site plugin extensions for Wix CLI applications. Site plugins are custom elements that integrate into predefined **slots** within Wix business solutions (like Wix Stores, Wix Bookings, Wix eCommerce), extending their functionality and user experience.
+Site plugins are custom elements that integrate into predefined **slots** within Wix business solutions (Wix Stores, Wix Bookings, Wix eCommerce, etc.), extending their functionality and user experience. Site owners place site plugins into UI slots using the plugin explorer in Wix editors.
 
-Site owners can place site plugins into UI slots using the plugin explorer in Wix editors.
+## Scaffold
 
-## Quick Start Checklist
-
-Follow these steps in order when creating a site plugin:
-
-1. [ ] Create plugin folder: `src/extensions/site/plugins/<plugin-name>/`
-2. [ ] Create `<plugin-name>.tsx` extending `HTMLElement` with `observedAttributes`
-3. [ ] Create `<plugin-name>.panel.tsx` with WDS components and `widget.getProp/setProp`
-4. [ ] Create `<plugin-name>.extension.ts` with `extensions.sitePlugin()` and unique UUID
-5. [ ] Update `src/extensions.ts` to import and use the new extension
+Use `wix generate --params` with `extensionType: SITE_PLUGIN`. `slotId` is `<componentId>:<slotId>` — the colon-joined widget component ID and slot ID. Run `wix schema generate --type SITE_PLUGIN` to list the available `slotId` values (each `anyOf` entry has the slot's human-readable title). The CLI generates the folder, the plugin `.tsx`, the settings panel `.tsx`, the builder file, the UUID, the logo SVG, and the `src/extensions.ts` registration.
 
 ## Architecture
 
-Site plugins consist of **three required files**:
+Site plugins consist of **three required files** generated by the CLI:
 
 ### 1. Plugin Component (`<plugin-name>.tsx`)
 
@@ -40,13 +32,9 @@ Settings panel shown in the Wix Editor sidebar:
 - Widget properties are bound to custom element attributes — any property change automatically updates the corresponding attribute
 - Wrapped in `WixDesignSystemProvider > SidePanel > SidePanel.Content`
 
-### 3. Extension Configuration (`<plugin-name>.extension.ts`)
-
-Defines the plugin's placement configuration:
+### 3. Extension Builder (`<plugin-name>.extension.ts`)
 
-- Specifies which slots the plugin can be added to
-- Configures auto-add behavior on app installation
-- Sets the tag name and file paths
+Generated by the CLI with placements, tagName, element/settings paths, marketData (name/description/logoUrl), and `installation.autoAdd`. Edit `marketData.description` and `installation.autoAdd` directly in this file after scaffolding if defaults don't match your needs.
 
 ## Plugin Component Pattern
 
@@ -255,26 +243,12 @@ Site plugins use **kebab-case** consistently for HTML attributes:
 | `<plugin>.tsx` (observedAttributes) | kebab-case | `['display-name', 'bg-color']`     |
 | `<plugin>.panel.tsx` (widget API) | kebab-case | `widget.getProp('display-name')`   |
 
-## Output Structure
-
-Site plugins live under `src/extensions/site/plugins`. Each plugin has its own folder with files named after the plugin.
-
-```
-src/extensions/site/plugins/
-└── {plugin-name}/
-    ├── {plugin-name}.tsx           # Main plugin component (HTMLElement)
-    ├── {plugin-name}.panel.tsx     # Settings panel component
-    └── {plugin-name}.extension.ts  # Extension registration
-public/
-└── {plugin-name}-logo.svg          # Plugin logo (optional)
-```
-
 ## References
 
 | Topic | Reference |
 | --- | --- |
 | Complete Examples | [EXAMPLES.md](site-plugin/EXAMPLES.md) |
-| Slots (App IDs, multiple placements, finding slots) | [SLOTS.md](site-plugin/SLOTS.md) |
+| Slots (App IDs, runtime APIs, design guidelines, multiple placements) | [SLOTS.md](site-plugin/SLOTS.md) — run `wix schema generate --type SITE_PLUGIN` for the authoritative `slotId` enum |
 | WDS Components | the `wix-design-system` skill |
 
 ## Available Slots
@@ -287,65 +261,7 @@ Site plugins integrate into predefined slots in Wix business solutions. Each slo
 
 Common placement areas include product pages (Wix Stores), checkout and side cart (Wix eCommerce), booking pages (Wix Bookings), service pages, event pages, and blog post pages.
 
-For supported pages, common Wix App IDs, and how to find slot IDs, see [SLOTS.md](site-plugin/SLOTS.md).
-
-## Extension Registration
-
-**Extension registration is MANDATORY and has TWO required steps.**
-
-### Step 1: Create Plugin-Specific Extension File
-
-Each site plugin requires an extension file in its folder:
-
-```typescript
-// my-site-plugin.extension.ts
-import { extensions } from '@wix/astro/builders';
-
-export default extensions.sitePlugin({
-  id: '{{GENERATE_UUID}}',
-  name: 'My Site Plugin',
-  marketData: {
-    name: 'My Site Plugin',
-    description: 'Marketing Description',
-    logoUrl: '{{BASE_URL}}/my-site-plugin-logo.svg',
-  },
-  placements: [{
-    appDefinitionId: 'a0c68605-c2e7-4c8d-9ea1-767f9770e087',
-    widgetId: '6a25b678-53ec-4b37-a190-65fcd1ca1a63',
-    slotId: 'product-page-details-6',
-  }],
-  installation: { autoAdd: true },
-  tagName: 'my-site-plugin',
-  element: './extensions/site/plugins/my-site-plugin/my-site-plugin.tsx',
-  settings: './extensions/site/plugins/my-site-plugin/my-site-plugin.panel.tsx',
-});
-```
-
-**CRITICAL: UUID Generation**
-
-The `id` must be a unique, static UUID v4 string. Generate a fresh UUID for each extension - do NOT use `randomUUID()` or copy UUIDs from examples. Replace `{{GENERATE_UUID}}` with a freshly generated UUID like `"95a28afd-7df1-4e09-9ec1-ce710b0389a0"`.
-
-| Property                   | Type    | Description                                                     |
-| -------------------------- | ------- | --------------------------------------------------------------- |
-| `id`                       | string  | Unique static UUID v4 (generate fresh)                          |
-| `name`                     | string  | Internal name for the plugin                                    |
-| `marketData.name`          | string  | Display name in plugin explorer and app dashboard               |
-| `marketData.description`   | string  | Description shown in plugin explorer and app dashboard          |
-| `marketData.logoUrl`       | string  | Path to logo file (`{{BASE_URL}}` resolves to public folder)    |
-| `placements`               | array   | Array of slot placements where plugin can be added              |
-| `placements.appDefinitionId` | string | ID of the Wix app containing the slot                          |
-| `placements.widgetId`      | string  | ID of the page containing the slot                              |
-| `placements.slotId`        | string  | ID of the specific slot                                         |
-| `installation.autoAdd`       | boolean | Whether to auto-add plugin to slots on app installation       |
-| `tagName`                  | string  | HTML custom element tag (kebab-case, must contain a hyphen)     |
-| `element`                  | string  | Relative path to plugin component                               |
-| `settings`                 | string  | Relative path to settings panel component                       |
-
-### Step 2: Register in Main Extensions File
-
-**CRITICAL:** After creating the plugin-specific extension file, you MUST read [Extension Registration reference](EXTENSION_REGISTRATION.md) and follow the "App Registration" section to update `src/extensions.ts`.
-
-**Without completing Step 2, the site plugin will not be available in the plugin explorer.**
+For App Definition IDs, per-slot runtime APIs, design guidelines, and placement constraints, see [SLOTS.md](site-plugin/SLOTS.md). Run `wix schema generate --type SITE_PLUGIN` for the authoritative `slotId` enum.
 
 ## Checkout Plugins
 

package/skills/wix-app/references/backend-event/COMMON-EVENTS.md

@@ -10,17 +10,6 @@ This reference lists common event types, SDK imports, permissions, and links. Fo
 | Contact updated | `import { contacts } from "@wix/crm"` | `contacts.onContactUpdated(handler)` | `SCOPE.DC-CONTACTS.READ-CONTACTS` | [onContactUpdated](https://dev.wix.com/docs/api-reference/crm/members-contacts/contacts/contacts/contact-v4/contact-updated?apiView=SDK) |
 | Contact deleted | `import { contacts } from "@wix/crm"` | `contacts.onContactDeleted(handler)` | `SCOPE.DC-CONTACTS.READ-CONTACTS` | [onContactDeleted](https://dev.wix.com/docs/api-reference/crm/members-contacts/contacts/contacts/contact-v4/contact-deleted?apiView=SDK) |
 
-**Example – contact created:**
-
-```typescript
-import { contacts } from "@wix/crm";
-
-export default contacts.onContactCreated((event) => {
-  const contact = event.entity;
-  console.log("New contact:", contact._id, contact.primaryInfo?.email);
-});
-```
-
 ## eCommerce Events
 
 | Event | Import | Handler Call | Permission | API Reference |
@@ -30,17 +19,6 @@ export default contacts.onContactCreated((event) => {
 | Cart created | `import { cart } from "@wix/ecom"` | `cart.onCartCreated(handler)` | `SCOPE.DC-STORES.READ-ORDERS` | [onCartCreated](https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/purchase-flow/cart/cart/cart-created?apiView=SDK) |
 | Cart updated | `import { cart } from "@wix/ecom"` | `cart.onCartUpdated(handler)` | `SCOPE.DC-STORES.READ-ORDERS` | [onCartUpdated](https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/purchase-flow/cart/cart/cart-updated?apiView=SDK) |
 
-**Example – order approved:**
-
-```typescript
-import { orders } from "@wix/ecom";
-
-export default orders.onOrderApproved(async (event) => {
-  const order = event.data.order;
-  console.log("Order approved:", order._id);
-});
-```
-
 ## Bookings Events
 
 | Event | Import | Handler Call | Permission | API Reference |
@@ -48,17 +26,6 @@ export default orders.onOrderApproved(async (event) => {
 | Booking confirmed | `import { bookings } from "@wix/bookings"` | `bookings.onBookingConfirmed(handler)` | `SCOPE.DC-BOOKINGS.READ-CALENDAR-WITH-PARTICIPANTS` | [onBookingConfirmed](https://dev.wix.com/docs/api-reference/business-solutions/bookings/bookings/bookings-writer-v2/booking-confirmed?apiView=SDK) |
 | Booking canceled | `import { bookings } from "@wix/bookings"` | `bookings.onBookingCanceled(handler)` | `SCOPE.DC-BOOKINGS.READ-CALENDAR-WITH-PARTICIPANTS` | [onBookingCanceled](https://dev.wix.com/docs/api-reference/business-solutions/bookings/bookings/bookings-writer-v2/booking-canceled?apiView=SDK) |
 
-**Example – booking confirmed:**
-
-```typescript
-import { bookings } from "@wix/bookings";
-
-export default bookings.onBookingConfirmed((event) => {
-  const booking = event.data.booking;
-  console.log("Booking confirmed:", booking._id);
-});
-```
-
 ## Blog Events
 
 | Event | Import | Handler Call | Permission | API Reference |
@@ -66,17 +33,6 @@ export default bookings.onBookingConfirmed((event) => {
 | Post created | `import { posts } from "@wix/blog"` | `posts.onPostCreated(handler)` | `SCOPE.DC-BLOG.READ-BLOGS` | [onPostCreated](https://dev.wix.com/docs/api-reference/business-solutions/blog/posts-stats/post-created?apiView=SDK) |
 | Post updated | `import { posts } from "@wix/blog"` | `posts.onPostUpdated(handler)` | `SCOPE.DC-BLOG.READ-BLOGS` | [onPostUpdated](https://dev.wix.com/docs/api-reference/business-solutions/blog/posts-stats/post-updated?apiView=SDK) |
 
-**Example – post created:**
-
-```typescript
-import { posts } from "@wix/blog";
-
-export default posts.onPostCreated((event) => {
-  const post = event.entity;
-  console.log("Post created:", post._id, post.title);
-});
-```
-
 ## Payload Shape
 
 The event envelope structure varies by API — the path to the main entity differs (e.g., `event.entity`, `event.data.order`). Use TypeScript and your IDE for autocomplete and type safety. See each event's API reference link above for the exact payload shape.