Shopify GraphQL API Requests
In Arigato Automation, the "Send a Shopify GraphQL API request" action allows you to send Query and Mutation requests to the Shopify GraphQL API.
The Shopify GraphQL API allows you add, update, get, and delete nearly any type of Shopify resource.
It is recommended that you are familiar with how to make Shopify GraphQL API requests to use this action type.
View Shopify GraphQL API Documentation
Pro Tips
Use AI to write custom GraphQL Queries for you. The built-in Mr. Arigato chat bot will save you loads of time and give you contextual advice. To get started, look for the magic wand in the upper right corner when configuring the Action.
Use Custom Action syntax in the Response field. With the power of Custom Actions, you can combine code, Shopify GraphQL API Requests, and even queue up other Workflows or additional Actions in one place. Custom Action documentation is built into the app. From the left sidebar in the app, click on "Code Reference" and scroll to the Custom Action section for more information, or ask the chat bot for help. All Custom Action syntax works within the Response field.
Action Configuration
Override Action Label
By default the action label will show the default action label that is entered:
You can override the label to help describe what your custom API request is actually for:
Query
Queries are equivalent to making a GET request in REST. A Mutation is the equivalent of making a POST or PUT request in REST. The Query field accepts both Queries and Mutations.
This example Query gets the names of all shop locations.
{ locations(first: 100) { edges { node { name } } } }
Variables
A json array of variables you would like to send to the query.
Example 1: Query using Variables
query($id: ID!) { node(id: $id) { ... on Product { id title productType } } }
Example 1: Variables Using JSON
{ "id": "gid://shopify/Product/7095788273845" }
Example 2: Query using Variables
query ($my_query: String){ products(first: 10, query: $my_query) { edges { node { id title handle } } } }<br>
Example 2: Variables Using Twig Variables, Rendering JSON
{% set my_sku = 'abcd' %} {"my_query": "sku:{{my_sku}}"}
Example 2: Rendered Twig Variables
{ "my_query": "sku:abcd" }
Response
The Response field uses Custom Action syntax. Documentation for Custom Actions is built into the app. Check the Code Reference in the left sidebar or as the Chatbot for help. You can also access the Custom Action documentation online at https://apps.bonify.io/twig#section-custom-action-reference--overview
Responses use Twig code. This allows developers to process the response in any way they'd like. For example, a developer could loop over all the data and selectively send some data to another workflow for further processing, or call other Actions directly from the Response.
Graph API Version
The action uses whatever version of the API the app is using. The current version is listed in the help bubble next to the Query.
Query Cost & Throttle Status
Calls to the Graph API are subject to Shopify's rate limiting, which is represented using a query cost. cost data is available in the response object for use when processing the returned data. Logs will also include the Throttle Status at the time the call was made and logged.
Accessing the cost information during processing can be done by debugging the cost variable:
{{ response.extensions.cost | debug }}
When an "expensive" query is run, the Action will fail with a message directly from Shopify. For example:
Query cost is 15002, which exceeds the single query max cost limit (1000). See https://shopify.dev/concepts/about-apis/rate-limits for more information on how the cost of a query is calculated.
Large individual queries must be broken into smaller, more manageable chunks, as they simply do not comply with Shopify's query size limits.
Too many small queries happening too quickly can also cause a query cost issue. Workarounds for this type of issue include adding a Delay Condition or setting the "Wait to fire" Advanced Setting to "1 minute" to allow the Query cost bucket to replenish before making another call. Calling QUEUE_ACTION or QUEUE_WORKFLOW rather than RUN_ACTION within a Response will utilize in-app throttling which manages cost overruns.