Wix's business solutions, such as eCommerce, Bookings, and Payments, run prebuilt flows for things like calculating tax, quoting shipping, validating a checkout, or charging a customer. Wix lets you inject your own code into those flows at specific decision points.
Service plugins are the platform-managed way to inject custom code at those decision points. A decision point is a specific step in a Wix flow where the platform pauses, calls your code, and continues based on what you return.
For example, a checkout process gathers a cart, applies discounts, calculates tax and shipping, validates the result, and submits a payment. The steps whose outcome depends on your own logic, such as a custom fee or a custom shipping rate, are the checkout decision points.
A service plugin can either:
- Add logic to an existing flow. For example, an extra fee or a validation rule at checkout.
- Provide something a flow depends on. For example, acting as a shipping-rate provider, a payment provider, or an external product catalog.
The pattern is inverted from a normal API call. Your code doesn't initiate the conversation. Instead, Wix does during one of its own flows. Wix sends a request describing the current state, such as the cart, the checkout, the booking, or the form submission, and your response feeds back into the rest of the flow.
Each decision point defines a contract for the shape of the request Wix sends and the response Wix expects back. The response must be returned per the specification exactly as documented or Wix will not handle your response correctly.
Because the plugin runs inside a live flow, Wix waits only for a limited time before moving on.
If your code is too slow or returns an error, the outcome depends on the decision point. The result can be:
- Continue without your contribution. For example, an additional-fees plugin that misses its time budget is skipped, and the checkout completes without the fee.
- Block the operation. For example, a booking validation that times out can stop the booking from going through.
The exact time budget and fallback behavior are defined per decision point in the API Reference.
Decision points are exposed across several Wix business solutions. The main ones include:
- eCommerce and Stores: Shipping rates, additional fees, tax calculation, discount triggers, cart and checkout validations, payment settings, gift cards, and connecting an external product catalog or inventory.
- Bookings: Custom pricing for a booking.
- CRM and forms: Additional validations on a form submission.
- Marketing and SEO: SEO keyword suggestions in the dashboard.
- Payments: Integrating a payment service provider.
- CMS: Connecting an external database as a data source.
- Automations: Providing a custom automated action.
- App billing: Charging Wix users for using your app.
The available decision points change over time, and not all of them are supported on every development path. For authentication and permission details when implementing a service plugin, see Service Plugins.
The development path determines how you register custom logic and where it runs:
- Sites: Implement custom logic for a single site by adding a service plugin file to the site's backend code. These files use Velo syntax even on sites where the rest of the backend is written with the SDK. For implementation, see Implement Service Plugins in Extend Websites.
- Wix-managed headless projects: Implement custom logic as a service plugin extension. Wix hosts the methods and the CLI generates the file structure and contract scaffolding. For implementation, see Add a Service Plugin with the CLI.
- Self-managed headless projects: Have no documented way to add a service plugin. Registering one through the Wix CLI requires Wix's Astro integration, which self-managed projects don't use.
- Wix-managed apps: Implement custom logic as a service plugin extension. Wix hosts the methods and the CLI generates the file structure and contract scaffolding. For implementation, see Add a Service Plugin with the CLI.
- Self-managed apps: Expose methods from their own backend that satisfy each decision point's contract. The app registers which decision points it implements, and Wix calls those methods during the relevant flows. For implementation, see Add Self-Hosted Service Plugin Extensions with the SDK or with REST in Build Apps.
- Blocks apps: Don't support service plugin extensions in their backend. An app that uses Blocks for UI can still register service plugins by adding a CLI or self-hosted component to the app for the service plugin logic.
For the request and response contract of each decision point, see the individual service plugin pages in the API Reference.