Skip to main content

Bulk Delete SKU Orders

POST 
/api/storefront/instances/:id/orders/bulk-delete-sku-orders

Delete the SKU.io sales orders that were created from these store orders, while keeping the mirrored store orders themselves. Use it to undo a bad import without losing the mirror.

Not yet available to API tokens

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

Both selection paths are narrowed to orders that actually have a linked SKU sales order — unlinked orders are never counted, so total_orders reflects real work. An order whose SKU sales order has returns already consumed against it is reported as a failure rather than deleted.

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.
  • archive_orders (boolean, optional, default false) — also archive each mirrored store order, which stops the next import run simply recreating the SKU sales order you just deleted.

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.

Requires the integrations.update permission.

Authentication: Bearer token (session or PAT).

Request​

Responses​

OK

Response Headers
    Content-Type