Welcome! An introduction to Mechanic

I'm glad you're here. :) I'm Isaac, and I built Mechanic. My intent is to make automation better for everyone. We do this, here, in two parts: (1) by making it as easy and fast as possible for developers to create something that specifically addresses a merchant's need, and (2) by making the configuration/management piece as easy and fast as possible for merchants. Mechanic is very, very good at both parts.

From the ground up, Mechanic was built to be composable and reusable – and if we consider all that power to be "under the hood", the hood is  extraordinarily thin.

What it does

  1. A developer writes a few lines of Liquid code. Or, a merchant installs a task from our library.
  2. The merchant configures the task using an auto-generated form – each element automatically feeding a data source in the task's code.
  3. The Mechanic platform handles responding to events coming from Shopify, from incoming email, from webhooks, etc. Scaling, uptime, monitoring, all sorted.

To get an idea of what Mechanic's been used for, have a look at our task library, at usemechanic.com. The code for each task is published, and each one can be modified. Mechanic is a highly versatile and incredibly powerful way to handle your process needs.

How it works

Mechanic has four core concepts: events, tasks, actions, and – beneath all of these – runs. In their natural order:

  1. An event occurs, usually triggered by something in Shopify.
  2. Mechanic renders whatever tasks apply to that event.
  3. Mechanic executes whatever actions those tasks define.
  4. Every event, task, and action has a run, representing the effort that Mechanic takes to do the work behind that event, task, or action.

(See the "Core concepts" section below for a more in-depth review.)

Importantly, we also have Liquid. You'll encounter this pretty much everywhere in Mechanic: it's a template language created by Shopify, and we use it heavily here, with a few extensions of our own. Read more about Liquid at Mechanic – strongly recommended reading. :)

Finally, if you're reading this, you're probably interested in reading from and writing to Shopify. Skipping ahead just a bit: you'll read data using Liquid (see Querying Shopify), and you'll write data using the "shopify" action.

How to learn

Mechanic has layers. :) If you're not looking to get into the code, then start by pulling tasks from our library, and experimenting with them. Mechanic is designed to be friendly, but if you've got questions, join our community Slack and ask away. If you know you want to find a developer to work with, then hop in the #jobs channel (more on that here: I need something custom – what next?).

If you are looking to get into the code, we have resources for you:

Core concepts

And now, a more in-depth review of how this whole thing works. :)


Events can be triggered by nearly anything you like. All webhooks from Shopify are supported, in addition to scheduler events and events triggered by a user within Mechanic. We also have our own webhook system, allowing you to create custom events from your own applications, or in-browser from your Shopify store.

Mechanic responds to each event by running any tasks that are configured for that event topic.

Read more about events


A task is a Liquid template, which we refer to as a "script" (see Scripts). When an event comes in, Mechanic uses the event data to render that script. Each task script is responsible for rendering JSON definitions of  actions, which will then be run.

Mechanic comes with 200+ tasks, already in our library. The Liquid code for each one is available online (see usemechanic.com), and is open-sourced on GitHub (see lightward/mechanic-tasks).

Read more about tasks


An action is a discrete instruction to do something. This is frequently an API request to Shopify, or an email to be sent, or a file to be uploaded to FTP, or an HTTP request to a third-party API. And, the results of actions can be re-used, triggering a new event, which can then kick off the entire cycle again.

Read more about actions


Whenever Mechanic does a piece of work (be it an event, a task, or an action), it does so using a run. A run can be delayed, or retried, and a run will usually be linked to other runs as well (since an event run results in a task run, which results in an action run).

This is a hugely important part of Mechanic's work model. If you're building things with Mechanic, make sure you understand these!

Read more about runs

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.