Work with your data at a granular level or as a complete set. The new trigger parameter exposes the complete Shopify webhook payloads in your code effects so your data is always available in the format you need.

Previously, Gadget only handled Shopify webhook subscriptions for you by automatically splitting a single webhook payload into multiple data models. For example, products/create webhooks are split into the Product, Product Variant, Product Image, and Product Options models. This is great when trying to work with these models separately, but sometimes you just want the entire webhook payload, especially when forwarding Shopify webhook data to an existing service, such as an ERP.

Nobody should have to stitch webhook payloads back together again — that’s time that could be spent on your actual app build. Now, we expose the complete webhook in a new parameter, readily-available in your Shopify model’s code effects: the trigger parameter.

With the trigger parameter, it’s easy to forward the complete webhook data to an existing service while Gadget manages Shopify’s API rate limits, scales up infrastructure, and handles a robust webhook connection and data sync:

You can also use different trigger types to determine when to run blocks of code. When you sync data from Shopify to Gadget for the first time, you may not want to send webhook payloads to a service. Using trigger, you can differentiate between an incoming sync and webhook trigger and choose to only run your code on incoming webhooks.

If you want to read more about the trigger parameter, all the details and information is available in our documentation. Have questions or feedback? Join our developer Discord to talk with the Gadget team and community.