Skip to main content
object

A job corresponds to some long running task that the client should poll for status.

•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.

•QueryRoot

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.


Was this section helpful?

•query

Returns a Job resource by ID. Used to check the status of internal jobs and any applicable changes.


Was this section helpful?

•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 Collection.sortOrder must be MANUAL.

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 newPosition: N.
  • Each move is applied sequentially in the order provided.
  • newPosition 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 newPosition 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.

•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 collectionUpdate 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 publishablePublish and publishableUnpublish 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 or saved_search_id argument 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.


Caution

Order cancellation is irreversible. An order that has been cancelled can't be restored to its original state.


Use the orderCancel 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 orderCancel 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 orderUpdate.

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 refundCreate 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 priceListFixedPricesByProductBulkUpdate 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 ProductDuplicateAsyncV2.

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

Submits a UrlRedirectImport request to be processed.

The UrlRedirectImport request is first created with the urlRedirectImportCreate mutation.


Was this section helpful?