A job corresponds to some long running task that the client should poll for status.
Anchor to FieldsFields
- Anchor to donedone•Boolean!non-null
This indicates if the job is still queued or has been run.
- •ID!non-null
A globally-unique ID that's returned when running an asynchronous mutation.
- Anchor to queryquery•Query
Root This field will only resolve once the job is done. Can be used to ask for object(s) that have been changed by the job.
Anchor to QueriesQueries
- •query
Returns a Job resource by ID. Used to check the status of internal jobs and any applicable changes.
Anchor to MutationsMutations
- •mutation
Asynchronously adds a set of products to a given collection. It can take a long time to run. Instead of returning a collection, it returns a job which should be polled.
- •mutation
Removes a set of products from a given collection. The mutation can take a long time to run. Instead of returning an updated collection the mutation returns a job, which should be polled. For use with manual collections only.
- •mutation
Asynchronously reorders products within a specified collection. Instead of returning an updated collection, this mutation returns a job, which should be polled. The
must be
.
How to use this mutation:
- Provide only the products that actually moved in the
moves
list; do not send the entire product list. For example: to move the product at index 1 to index N, send a single move for that product with.
- Each move is applied sequentially in the order provided.
is a zero-based index within the collection at the moment the move is applied (after any prior moves in the list).
- Products not included in
moves
keep their relative order, aside from any displacement caused by the moves. - If
is greater than or equal to the number of products, the product is placed at the end.
Example:
- Initial order: [A, B, C, D, E] (indices 0..4)
- Moves (applied in order):
- E -> newPosition: 1
- C -> newPosition: 4
- Result: [A, E, B, D, C]
Displaced products will have their position altered in a consistent manner with no gaps.
- Provide only the products that actually moved in the
- •mutation
Updates a collection, modifying its properties, products, or publication settings. Collections help organize products together in the online store and other sales channels.
Use the
mutation to programmatically modify collections in scenarios such as:
- Updating collection details, like title, description, or image
- Modifying SEO metadata for better search visibility
- Changing which products are included (using rule updates for smart collections)
- Publishing or unpublishing collections across different sales channels
- Updating custom data using metafields
There are two types of collections with different update capabilities:
- Custom (manual) collections: You can update collection properties, but rule sets can't be modified since products are manually selected.
- Smart (automated) collections: You can update both collection properties and the rules that automatically determine which products are included.
When updating rule sets for smart collections, the operation might be processed asynchronously. In these cases, the mutation returns a
job
object that you can use to track the progress of the update.
To publish or unpublish collections to specific sales channels, use the dedicated
and
mutations.
Learn more about using metafields with smart collections.
- •mutation
Merges two customers.
- •mutation
Enqueue the removal of a delivery profile.
- •mutation
Asynchronously delete automatic discounts in bulk if a
search
orargument is provided or if a maximum discount threshold is reached (1,000). Otherwise, deletions will occur inline. Warning: All automatic discounts will be deleted if a blank
search
argument is provided.- •mutation
Activates multiple code discounts asynchronously using one of the following:
- A search query
- A saved search ID
- A list of discount code IDs
For example, you can activate discounts for all codes that match a search criteria, or activate a predefined set of discount codes.
- •mutation
Deactivates multiple code-based discounts asynchronously using one of the following:
- A search query
- A saved search ID
- A list of discount code IDs
For example, you can deactivate discounts for all codes that match a search criteria, or deactivate a predefined set of discount codes.
- •mutation
Deletes multiple code-based discounts asynchronously using one of the following:
- A search query
- A saved search ID
- A list of discount code IDs
For example, you can delete discounts for all codes that match a search criteria, or delete a predefined set of discount codes.
- •mutation
Asynchronously delete discount codes in bulk that customers can use to redeem a discount.
- •mutation
Adds tags to multiple draft orders.
- •mutation
Deletes multiple draft orders.
- •mutation
Removes tags from multiple draft orders.
- •mutation
Deletes all external marketing activities. Deletion is performed by a background job, as it may take a bit of time to complete if a large number of activities are to be deleted. Attempting to create or modify external activities before the job has completed will result in the create/update/upsert mutation returning an error.
- •mutation
Updates a metafield definition.
- •mutation
Asynchronously delete metaobjects and their associated metafields in bulk.
- •mutation
Cancels an order, with options for refunding, restocking inventory, and customer notification.
CautionOrder cancellation is irreversible. An order that has been cancelled can't be restored to its original state.
Use the
mutation to programmatically cancel orders in scenarios such as:
- Customer-requested cancellations due to size, color, or other preference changes
- Payment processing failures or declined transactions
- Fraud detection and prevention
- Insufficient inventory availability
- Staff errors in order processing
- Wholesale or B2B order management workflows
The
mutation provides flexible refund options including refunding to original payment methods or issuing store credit. If a payment was only authorized (temporarily held) but not yet charged, that hold will be automatically released when the order is cancelled, even if you choose not to refund other payments.
The mutation supports different cancellation reasons: customer requests, payment declines, fraud, inventory issues, staff errors, or other unspecified reasons. Each cancellation can include optional staff notes for internal documentation (notes aren't visible to customers).
An order can only be cancelled if it meets the following criteria:
- The order hasn't already been cancelled.
- The order has no pending payment authorizations.
- The order has no active returns in progress.
- The order has no outstanding fulfillments that can't be cancelled.
Orders might be assigned to locations that become deactivated after the order was created. When cancelling such orders, inventory behavior depends on payment status:
- Paid orders: Cancellation will fail with an error if restocking is enabled, since inventory can't be returned to deactivated locations.
- Unpaid orders: Cancellation succeeds but inventory is not restocked anywhere, even when the restock option is enabled. The committed inventory effectively becomes unavailable rather than being returned to stock at the deactivated location.
After you cancel an order, you can still make limited updates to certain fields (like notes and tags) using the
.
For partial refunds or more complex refund scenarios on active orders, such as refunding only specific line items while keeping the rest of the order fulfilled, consider using the
mutation instead of full order cancellation.
Learn how to build apps that integrate with order management and fulfillment processes.
- •mutation
Creates a payment for an order by mandate.
- •mutation
Updates the fixed prices for all variants for a product on a price list. You can use the
mutation to set or remove a fixed price for all variants of a product associated with the price list.
- •mutation
Duplicates a product.
If you need to duplicate a large product, such as one that has many variants that are active at several locations, you might encounter timeout errors.
To avoid these timeout errors, you can instead duplicate the product asynchronously.
In API version 2024-10 and higher, include
synchronous: false
argument in this mutation to perform the duplication asynchronously.In API version 2024-07 and lower, use the asynchronous
.
Metafield values are not duplicated if the unique values capability is enabled.
- •mutation
Asynchronously reorders the media attached to a product.
- •mutation
Asynchronously queries and charges all subscription billing cycles whose billingAttemptExpectedDate values fall within a specified date range and meet additional filtering criteria. The results of this action can be retrieved using the subscriptionBillingCycleBulkResults query.
- •mutation
Asynchronously queries all subscription billing cycles whose billingAttemptExpectedDate values fall within a specified date range and meet additional filtering criteria. The results of this action can be retrieved using the subscriptionBillingCycleBulkResults query.
- •mutation
Create or update theme files.
- •mutation
Asynchronously delete URL redirects in bulk.
- •mutation
Asynchronously delete URLRedirect objects in bulk by IDs. Learn more about URLRedirect objects.
- •mutation
Asynchronously delete redirects in bulk.
- •mutation
Asynchronously delete redirects in bulk.
- •mutation