Skip to main content

Bulk Void Shipments

DELETE 
/api/sales-order-fulfillments

Bulk-voids shipments. The DELETE verb is retained for backwards compatibility, but it now performs a soft VOID (not a hard delete): each shipment's inventory is reversed, its parent FulfillmentOrder is reopened, the carrier order is cancelled, and the SOF row is kept for history (status=canceled + void audit columns).

Required scope: orders:write

Grant this scope to your token under Settings → Developer → Personal Access Tokens.

Request body: • ids (array<int>, required without apply_to_all): fulfillment IDs to void. • apply_to_all (bool, optional): when true, voids every shipment matching filters instead of ids. • filters (object, optional): the V2 list filter set used to resolve IDs when apply_to_all=true. • force (bool, optional, default false): when false, shipments already shipped at the provider are NOT voided — they land in the needs_confirmation bucket. Re-submit those with force=true to void the local copy anyway (inventory reversed, carrier order left as-is). • void_reason (string, optional, max 1000): reason recorded on each void + FO activity entry.

Selection size routing: • ≤ 30 shipments: voided synchronously; the response data carries per-shipment result buckets. • > 30 shipments: dispatched to a background tracked job; the response data carries tracked_job_log_id for the tracked job log endpoints.

Result buckets (synchronous): • voided[]: { id, fulfillment_number } — successfully voided. • needs_confirmation[]: { id, fulfillment_number, reason } — shipped at the provider; re-submit with force=true. • skipped[]: { id, fulfillment_number, reason } — already voided or otherwise not voidable. • errors[]: { id, fulfillment_number, error } — unexpected failures.

Authentication: Requires Bearer token.

Request​

Responses​

OK

Response Headers
    Content-Type