Changelog

Follow up on the latest improvements and updates.

RSS

Mechanic’s Google Sheets action is now much more capable.
Tasks can now work with multiple sheets in the same spreadsheet, manage sheet tabs, read and update ranges, clear values, and delete rows.
What’s new:
  • Create spreadsheets with multiple named sheets
  • Add, rename, and delete sheets
  • Update rows at a specific range
  • Clear values from a range
  • Read values from a range
  • Delete a range of rows
  • Choose whether Google treats written values as raw text or user-entered values
That last option is useful when you want Google Sheets to interpret dates, numbers, or formulas the same way it would if someone typed them into the spreadsheet.
This makes richer Google Sheets workflows possible directly from Mechanic: multi-tab reports, find-then-update flows, cleanup tasks, formatted exports, and spreadsheet automation that does not have to stop at “append a row”.
Existing Google Sheets tasks continue working as before.
Learn more:
Mechanic now supports shop-level globals and secrets.
Use globals for visible reusable values like API URLs, location IDs, thresholds, shared JSON settings, or other configuration that multiple tasks need.
Use secrets for sensitive strings like access tokens, signing keys, webhook tokens, private keys, or passwords. After a secret is saved, Mechanic does not show its raw value again.
Tasks can reference globals and secrets from Liquid:
{{ globals.api_base_url }}
{{ secrets.webhook_token }}
Task authors can also expose globals and secrets as task option inputs. Use
__global
and
__secret
option types to let the person configuring a task choose from saved shop values instead of pasting raw values into the task.
Secrets are intentionally not ordinary Liquid strings. They are only resolved in reviewed secret-aware places, including HTTP actions, FTP connection fields, OAuth flows, and signing filters.
The goal is simple: less duplication, safer credentials, and cleaner task configuration.
Learn more:
We’ve added a couple of small updates for keeping an eye on Shopify API versions and deprecations from your own tools.
The Mechanic CLI can now show each task’s configured Shopify API version:
mechanic tasks list
And it can list unresolved Shopify API deprecations reported by tasks in the shop:
mechanic shop deprecations
Use JSON output when you want to feed this into a script, agent, dashboard, or monitoring tool:
mechanic shop deprecations --json
This gives you another way to spot tasks that may need an API version review, without clicking through each task in the app.
Learn more:
Mechanic now has an
Activity
page.
Activity shows how Mechanic is operating in your shop: events received, events created, task runs, actions sent, failed runs, and the patterns behind them. You can drill down into the events behind the graphs.
Use it when you want to answer questions like:
  • Did a flood of Shopify events arrive?
  • Which event topics are busiest?
  • Which tasks are running the most?
  • Are failures concentrated in one task, action, or time period?
  • What happened around the time a merchant reported a problem?
  • Activity includes range controls, visual charts, summary cards, top contributors, and drilldowns into Events so you can move from “something changed” to the underlying runs.
This is designed for debugging and visibility :)
Mechanic now has a developer workflow for teams who want to manage tasks closer to their code, editors, AI tools, CI, and monitoring systems.
With API tokens, the Mechanic CLI, and the task sync API, you can pull tasks into local files, edit them in your own tools, preview changes safely, review diffs, and publish back to Mechanic when you're ready.
You can also monitor shop queue health from outside the app.
mechanic shop status --json
and the shop status API report waiting runs, running runs, queue lag, and the top tasks, actions, or event topics contributing to the wait. Use that with tools like Cronitor, UptimeRobot, Better Stack, Datadog, New Relic, or your own monitoring system.
What's new
  • Local task projects with
    mechanic init
  • Pull tasks into Git-friendly JSON files with
    mechanic tasks pull
  • Create new local tasks with
    mechanic tasks new
  • Edit Liquid, docs, subscriptions, and task settings locally
  • Preview local task changes without saving them
  • Diff local changes against the current Mechanic version
  • Publish task changes intentionally
  • Monitor shop queue health and queue lag
  • Optional GitHub Actions templates for validation, deploys, and sync-back
  • Better support for AI coding agents working with Mechanic tasks
How to use it
npm install -g @lightward/mechanic-cli
mechanic init --shop example.myshopify.com
mechanic tasks pull
mechanic tasks preview order-tagger
mechanic tasks diff order-tagger
mechanic tasks publish order-tagger
Monitor queue health
mechanic shop status
mechanic shop status --json
Or call the API endpoint directly with a Mechanic API token:
curl https://api.mechanic.dev/v1/shop/status \
-H "Authorization: Bearer $MECHANIC_API_TOKEN"
Learn more
Mechanic now supports Shopify bulk operation mutations
Mechanic can now monitor Shopify
bulkOperationRunMutation
jobs the same way it already monitors bulk operation queries, and return the completed JSONL results to your task using the existing
mechanic/shopify/bulk_operation
event.
Bulk operation mutations are useful when you need to run the same Shopify Admin API mutation many times. Your task prepares a JSONL file where each line contains the variables for one mutation run, uploads that file to Shopify, starts the bulk mutation, and then waits for Shopify to finish processing it asynchronously.
How it works
  1. Create a staged upload in Shopify.
  2. Upload a JSONL variables file.
  3. Start
    bulkOperationRunMutation
    with the staged upload path.
  4. Wait for Mechanic to receive the completed
    mechanic/shopify/bulk_operation
    event.
  5. Read the completed results from
    bulkOperation.objects
    .
Each result object represents the GraphQL response for one JSONL input line. This lets your task inspect which mutation runs succeeded, and which returned GraphQL errors or mutation
userErrors
.
This uses the same
bulkOperation
variable as bulk operation queries. If a task handles both operation types, check
bulkOperation.type
:
QUERY
for bulk operation queries, or
MUTATION
for bulk operation mutations.
Code editor snippets
We also added task code editor snippets for common bulk operation starters:
boilerplate:bulk_operation_query
boilerplate:staged_upload_jsonl
boilerplate:bulk_operation_mutation
Learn more
Mechanic now supports custom Shopify webhooks.
This gives advanced users a new way to receive Shopify webhook events in Mechanic, with Shopify filtering deliveries before they arrive, customizing payload fields, including metafields, and routing events onto custom
user/...
event topics.
This also unlocks something new for Mechanic: Shopify metaobject webhook event topics.
You can now create custom Shopify webhooks for:
shopify/metaobjects/create
shopify/metaobjects/update
shopify/metaobjects/delete
Each metaobject webhook uses a
type:
filter, so you can subscribe to the exact metaobject definition your task cares about. This filter is required by Shopify.
What this is good for:
  • receiving only matching Shopify webhook deliveries
  • routing product updates to one specific task instead of triggering every task subscribed to
    shopify/products/update
  • including known metafields directly in the webhook payload
  • subscribing to Shopify metaobject events
A practical example: product updates.
With a regular
shopify/products/update
subscription, every enabled task listening to that topic receives every product update. If you have 20 product-update tasks, all 20 are triggered, and each task has to decide whether the update matters.
With a custom Shopify webhook, Shopify can filter first, and Mechanic can route only the matching deliveries to a purpose-specific
user/...
topic, like
user/products/active_update
. That gives you a cleaner one-to-one path from a Shopify event to the task or workflow that should respond.
Most Shopify-triggered tasks should still use regular
shopify/...
subscriptions. Custom Shopify webhooks are for cases where Shopify-side filtering, payload customization, metafields, or metaobject events matter before the event reaches Mechanic.
A few gotchas:
  • Shopify webhook filters are not exactly the same as Shopify Admin search queries.
  • Payload customization does not make a webhook unique. Shopify only allows one enabled webhook for the same Shopify topic and filter, you can work around this with neutral filters like
    id:*
    and
    created_at:*
    .
  • Metaobject webhooks require a concrete type: filter.
We also cleaned up Mechanic’s Settings area, removing the old tab layout and making the growing set of settings easier to scan and navigate.
Learn more:
When preparing event webhooks to send to apps like Mechanic, Shopify uses payloads as defined by a specific version of their Webhook API.
Effective immediately, Shopify events in Mechanic now use webhook payloads from version 2026-04 of the Shopify Webhook API.
‼️ Shopify has flagged these webhook API changes as "Action Required" (source):
References
Mechanic now has app-wide keyboard shortcuts.
Use
Cmd/Ctrl + J
to toggle Ask Mechanic (our built-in AI assistant),
?
to open the shortcuts sheet, and sequence shortcuts like
g then g
to jump home.
You can also jump straight to the task library, events, settings, help, or a new task without reaching for the mouse.
Small feature, big quality-of-life upgrade.
image
Task exports now include each task’s unique ID.
This doesn’t change how imports work. If you import task JSON that contains an ID, Mechanic ignores it during import. The ID is included only for external record keeping, so you can reliably identify a task outside of Mechanic even if the task title changes later.
This is especially useful if you work with exported tasks in another tool and need a stable reference that isn’t tied to the task name.
Load More