Reference · built on requestConnectorCommerce & orders

Wix

Orders, fulfillments, payments, refunds, and inventory items from Wix Stores through the Wix REST API and webhooks.

About

Wix is a website builder whose Wix Stores app adds a catalog, checkout, and orders to a site. Each order records line items, buyer and shipping details, a price summary, and three statuses: status, paymentStatus, and fulfillmentStatus. Fulfillments, payments, refunds, and inventory items each have their own API under www.wixapis.com, and the site sends events as JWT-encoded webhooks.

Through Fibric, an operator reads orders and their transactions, then proposes a fulfillment with tracking, a refund within the paid balance, or a cancellation with restock. You approve. The connector makes the call once and leaves a record: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Wix and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders through Get Order and Search Orders, with status, paymentStatus, fulfillmentStatus, lineItems, buyerInfo, priceSummary, and balanceSummary
  • Order Approved, Order Updated, and Order Canceled webhooks; updated events include modifiedFields with each field's value before the change
  • Fulfillments per order through the Order Fulfillments API, with tracking info and a status from Pending to Fulfilled
  • Payment and refund records through the Order Transactions API, including chargebacks recorded on a payment
  • Inventory items per variant and location through Inventory Items V3, with quantity or inStock tracking and preorder settings
  • Inventory Item Updated and Inventory Item Stock Status Updated events

Proposed actions

  • Target capability: propose a fulfillment with tracking through the Order Fulfillments API, on an approved order, up to 300 line items
  • Target capability: propose a refund through Refund Payments, naming the paymentId, amount, line items, restock, and whether to email the customer
  • Target capability: propose cancelling an order through POST /ecom/v1/orders/{id}/cancel, with restockAllItems and an optional customMessage
  • Target capability: propose an Update Order change to contact info, addresses, or the archived flag
  • Target capability: propose an inventory quantity change through Bulk Increment or Bulk Decrement Inventory Items for a variant at a location

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Refund within the paid balance

    A support request asks for a partial refund. The operator reads the order's payments and prior refunds from Order Transactions, then proposes Refund Payments for the line items in question, with restock and a customer email.

    With Refund Policy

  • Cancel before it ships

    A buyer asks to cancel. The operator checks fulfillmentStatus and authorized transactions, then proposes the cancel call with restockAllItems and a note for the buyer. Orders already in delivery are routed to a person.

    With Cancellation Window

  • Tracking on every order

    When a carrier label is created elsewhere, the operator proposes a fulfillment on the Wix order with the tracking number; predefined carriers get a tracking link generated by Wix.

    With Tracking Sync

  • Watch for silent stock-outs

    Inventory Item Stock Status Updated fires when a variant's availability changes. The operator checks open orders for that variant and proposes an increment or a preorder setting for your approval.

    With Oversell Watch

Requirements

  • A Wix site with the Wix Stores app installed
  • An app instance or API key granted Manage Orders (SCOPE.DC-STORES.MANAGE-ORDERS); Read Orders (SCOPE.DC-STORES.READ-ORDERS) covers order webhooks
  • An HTTPS endpoint that decodes the JWT-encoded webhook payload and reads eventType, instanceId, and data
  • Refresh handling: app access tokens are short-lived; a 401 means the token expired and Create Access Token must be called again
Authentication
A token in the Authorization header: an app access token from Create Access Token with the client_credentials grant, or a long-lived API key sent with a wix-site-id header.

Limits

  • Update Order changes only contact info, addresses, and metadata. Pricing and line-item edits go through the Draft Orders API.
  • An order cannot be cancelled while PENDING, REJECTED, or holding an authorized transaction; void or refund the authorization first.
  • Fulfillments can only be created for approved orders. Bulk fulfillment covers 100 orders per call.
  • Checkout deducts stock from the default location only. Non-default locations are adjusted through the Inventory Items API.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Wix ↗

Questions and answers

Which permission does cancelling or refunding an order need?
Manage Orders, scope SCOPE.DC-STORES.MANAGE-ORDERS, covers Cancel Order and Refund Payments. Reading orders and receiving order webhooks needs Read Orders, SCOPE.DC-STORES.READ-ORDERS.
Does the Order Transactions API move money?
No. It records payments and refunds. To refund funds, the connector calls Refund Payments in the Order Billing API, which calls the payment provider unless externalRefund is true; the refund is then recorded in the order's transactions.
How does Wix deliver order events?
As REST webhooks with a JWT-encoded payload containing eventType, instanceId, data, and identity. Order Updated carries the full order plus modifiedFields showing prior values; its entityFqdn is wix.ecom.v1.order and its slug is updated.
Ask about Wix

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.