Skip to main content

Bulk Update SKU Orders

POST 
/api/storefront/instances/:id/orders/update-sku-orders

Re-read each order from the store, then push what changed into its linked SKU.io sales order: a store cancellation cancels the SKU sales order, a payment taken after import is recorded once, and the buyer's delivery choice is refreshed.

Not yet available to API tokens

This endpoint currently requires session authentication; Personal Access Token scope support is in progress.

Orders with no linked SKU sales order are skipped and reported. If the store cannot be reached for an order, that order is still updated from the last mirrored data rather than failing the batch — refetch_failed counts how many took that path.

Request body

  • ids (array of integers, required unless apply_to_all is sent).
  • apply_to_all (boolean, optional).
  • filters (object, nullable) — the set to target when apply_to_all is true.

Choosing the orders Send exactly one of the two selection shapes:

  • ids — an explicit list of mirrored order ids. Ids that belong to another connection are silently dropped.
  • apply_to_all: true plus filters — the action targets every order the filters match, however many that is, not just a page of them. The filters object is resolved server-side against the same filter set GET /orders accepts, so what you saw in the list is exactly what is acted on.

Inside filters (every key optional, all bare column names — no filter[...] brackets needed, though filter[status] style keys and a nested filter object are both unwrapped for you):

  • search — the same free-text search as the list, honoured like any other filter.
  • search_columns, search_strict_columns — narrow or tighten that search.
  • status, payment_status, currency_code — comma-separated value lists.
  • sku_order — with, without, abandoned, failed or held.
  • has_unmapped_items — boolean.
  • archived — only/archived, or all. Leaving it out means active orders only, matching the list's own default, so a filter-less apply-to-all never sweeps archived orders.
  • placed_from, placed_to — date bounds.
  • ids — a comma-separated id list, as a filter rather than a selection.
  • <column>.<operator> — any advanced operator key the list accepts (e.g. total.greater_than).
  • filter_groups — a base64-encoded JSON condition tree.

Pagination and display keys (page, per_page, sort, included, total, query) are ignored if present.

Failing closed. A filters payload that cannot be parsed, a malformed filter_groups tree, or a legacy {conjunction, filterSet} payload returns 422 rather than being treated as "no filters" — silently matching every order would be the wrong guess for a bulk action.

Immediate or background. A single order is processed inline and the outcome is in the response (tracked_job_log_id is null). More than one order is queued as a background task and the response returns straight away with tracked_job_log_id — the handle you poll for progress, per-order results and failures. total_orders is how many orders were selected.

A single order with no SKU sales order to update returns 422 rather than a silent success.

Requires the integrations.sync permission.

Authentication: Bearer token (session or PAT).

Request​

Responses​

OK

Response Headers
    Content-Type