AI workers for Shopify

What is an AI worker for Shopify?

An AI worker for Shopify is an AI agent scoped to one store-operations job, such as reporting yesterday's sales against last week or flagging the orders that need a human. It reaches the store through your connected Shopify admin credentials, and what it may read, what it may change, and how much money any single operation may move are all decided per worker before it runs.

What these workers do

The morning store brief

Yesterday's sales against the compare window, orders needing attention, refunds, and low stock on winners — one scheduled read-only run before the day starts.

Sweep the stuck orders

Unfulfilled beyond a threshold, payment problems, high-risk flags and return requests get listed with order numbers and a recommended action, on a cadence.

Guard the best sellers' stock

Top sellers ranked over the window with current stock joined in; any winner whose days-of-cover falls below the restock lead time gets flagged before it becomes an empty shelf.

Keep the catalog honest

Products missing images, thin descriptions or absent SEO fields get reported with their ids, so merchandising fixes stop depending on someone noticing.

Know the customers

Top spenders in the window, repeat rate, and previously-loyal buyers going quiet — computed from orders, with identity masking and contact rules applied throughout.

How an AI worker runs in Shopify

Money moves only under a cap you set

Your customers don't hear from your automation unless you say so

Reports are computed over complete data

Stock signals come with their homework done

Customer data stays on your terms

Shopify questions, answered.

Can a worker refund an order on its own?

Only when the refund permission is granted, and never past the cap. Refunds are a separate grant from reading or even editing orders, and the per-operation ceiling you set is enforced on every path money can leave — direct refunds, a cancellation's refund, and return processing alike. Over-refunding beyond what was paid is refused outright. Most stores start with a worker that drafts refund recommendations and holds no money permission at all.

Will shoppers get emails when a worker changes an order?

No, unless the account has deliberately allowed it. Every worker write that could notify a customer — cancellations, refunds, fulfillment and tracking updates — has its notification suppressed by default, because Shopify's own defaults vary call by call and automation should not surprise your customers. Turning shopper-facing notifications on is one explicit setting, made once, on purpose.

Which orders and customers can it see?

What the token's scope allows. Access can be limited to one store on multi-store accounts, to a sales channel, to tagged orders or customers, or to specific locations for inventory — and customer identity fields are separately maskable, so a triage worker can work the order queue without ever seeing who bought. Customers blocked by a contact rule vanish from lists entirely, and the response says items were withheld.

Why do reports say history is limited?

New Shopify app credentials see roughly the last 60 days of orders until the app is granted full-history access in the store's own settings. The reports and searches say so whenever a request reaches past the window, so a limited view is never mistaken for missing sales. Granting the read-all-orders scope on your app removes the limit, which matters most for lifetime-value and year-over-year comparisons.

Are stock alerts real-time?

They run on the worker's schedule and say so. A low-stock or stuck-order worker checks on the cadence you set, computes against complete data, remembers what it already raised so it only alerts on new crossings, and stays quiet otherwise. Tighten the schedule when a check needs to be faster. What you will not get is a silent gap: if the check could not complete, the run says so rather than reporting a false all-clear.

What AI workers can do in Shopify

The tools a worker can be granted in Shopify once you connect it. A kit grants only the ones its job needs, and you can narrow them further on the worker.

List Orders

List or search the store's orders newest first, each with payment/fulfillment/return status, totals, line items, fulfillments with tracking, refunds, risk assessment and acquisition attribution. Every filter is applied server-side by the store platform: status (open/closed/cancelled), financialStatus (paid, pending, authorized, partially_refunded, refunded...), fulfillmentStatus (unfulfilled, partial, fulfilled, on_hold...), returnStatus, riskLevel (high/medium/low), channel, tag, a created/updated date window (ISO 8601), a total-price range, sku, or customerId — so ask the narrow question rather than paging everything. Order history may be limited to the last 60 days by the connected app's scopes; when a request reaches past that, accessInfo says so — render accessInfo verbatim, and treat an empty list with a non-null accessInfo as scoping, not absence. Paginate with nextCursor into cursor (name a store first on multi-store accounts).

Get Order

Get one order in full: statuses, current-vs-original totals, line items, shipping address, fulfillments with tracking, refunds, risk assessment with its recommendation, acquisition attribution (UTM/referrer of the first visit; attribution is eventually consistent — 'ready' says whether it has settled), notes, tags and custom attributes. Pass includeTimeline=true to add the order's event history including staff timeline comments. Any field masked off for this token comes back null or empty with an explanatory accessInfo; render it verbatim.

List Customers

List or search customers, each with lifetime spend, order count, last order date, tags, marketing-consent state and store-credit balances. Filters are server-side: tag, state (enabled/invited/disabled/declined), a total-spend range (minSpent/maxSpent — the VIP filter), an updatedSince ISO-8601 window, or free text (name, email, phone). Contact rules may withhold specific customers and field masks may hide identity or contact details; accessInfo says what was limited — render it verbatim. Paginate with nextCursor into cursor.

Get Customer

Get one customer's profile: identity and contact details (as the token's field mask allows), lifetime spend, order count, last order, default address, tags, note, marketing-consent state and store-credit balances per currency. Pass includeOrders=true to include their ~10 most recent orders. A customer withheld by a contact rule returns an access denial rather than a partial profile; render accessInfo verbatim.

List Segments

List the store's saved customer segments — each with its name and the membership query the store platform evaluates it with. Use a segment's id with shopify_get_segment_members to read who is in it. Single-store operation: on multi-store accounts pass store.

Get Segment Members

List the customers in one saved segment (totalCount tells you the full size), each as a slim profile: id, name, lifetime spend and order count. Fetch a full profile with shopify_get_customer by id. Contact rules apply — withheld members are dropped and counted in accessInfo; render it verbatim.

Inventory Levels

Read stock per variant per location: available, on-hand, committed, reserved and incoming quantities, with SKU, product/variant titles and location names. belowThreshold returns only rows whose available quantity is strictly below the number — the per-location scan happens server-side here, because the store platform itself has no per-location quantity filter. 'incoming' reflects inventory transfers only; purchase orders are not exposed by the platform, so stock on order from suppliers is NOT included. Unit costs appear only when the token may see inventory_costs. Filter by locationId, sku or free text; paginate with nextCursor into cursor.

List Inventory Transfers

List inventory transfers between the store's locations: status, origin and destination, total and received quantities, tags and notes. Transfers are what feeds the 'incoming' quantity on inventory levels. Single-store operation: on multi-store accounts pass store.

List Products

List or search products with merchandising signals built in: status (active/archived/draft), media count (0 = no images), SEO title and description, description length (0 or tiny = thin copy), price range, total inventory and tags. Server-side filters: status, tag, vendor, productType, collectionId (products in one collection), outOfStockOnly (out of stock somewhere), an updatedSince ISO-8601 window, or free text. A token scoped to collections must pass collectionId. Paginate with nextCursor into cursor.

Get Product

Get one product in full: description HTML, SEO fields, tags, status, price range, media count and every variant with its SKU, barcode, price, compare-at price and inventory quantity. Tokens scoped to specific collections cannot use this direct read (membership is not verifiable on it) — use shopify_list_products with collectionId instead; the denial's accessInfo says exactly that.

List Collections

List the store's collections with product counts, sort order and kind: 'manual' collections hold an explicit product list; 'smart' collections are rule-driven and their membership cannot be edited directly. Use a collection's id as collectionId on shopify_list_products to read its members. Single-store operation.

List Discounts

List discount codes and automatic discounts: title, code (null for automatic ones), status, human-readable summary of what the discount does, active window, usage limit and how many times it has been used. Single-store operation: on multi-store accounts pass store.

Sales Report

Sales computed server-side over the window's complete order set (never sampled): revenue, order count, AOV, refunded amount and refund rate, units sold, new-vs-returning customer orders, a by-channel breakdown, and the top products. With compareTo set, the same totals for the comparison window plus percent deltas per metric — the one-call answer to 'how do we compare to last week/year'. ordersAnalyzed anchors every figure; if the window held more orders than one pass reads, accessInfo says the figures cover the analyzed subset — narrow the window for complete numbers. Amounts are in the store's currency and windows resolve in the store's own timezone.

Product Performance

Ranked sellers over the window WITH current stock joined in server-side: units sold, revenue, order count, daily velocity, current available stock, incoming stock, days-of-cover (available / velocity) and a stockoutRisk flag when cover is below your restock lead time. 'Top 10 best sellers vs inventory' is one call: topN=10, leadTimeDays=your supplier lead time. Set slowestFirst=true for the overstock view (slowest sellers first). Incoming reflects transfers only — supplier purchase orders are not exposed by the platform, so reorder advice should say 'no incoming transfer recorded', not 'nothing on order'. Never sampled; accessInfo reports any truncation.

Inventory Health

Per-location stock health, computed server-side: every tracked variant that is out of stock, low on cover, or overstocked — with available and incoming quantities, daily sales velocity over the velocity window, and days-of-cover. Rows that are simply fine are omitted, so the response IS the action list, ordered worst first. Thresholds are yours: lowCoverDays (default 14) and overstockCoverDays (default 180). Incoming reflects transfers only; purchase orders are invisible to the platform's API.

Customer Insights

Customer intelligence over the window, computed server-side: new vs returning customer orders and the repeat rate; the top customers by spend within the window (id, name, email as the field mask allows, spend, orders, last order date); and at-risk customers — previously-repeat buyers with no order in atRiskDays. Orders whose acquisition attribution has not settled yet are counted but not classified, and accessInfo says how many. Contact rules and identity/contact field masks apply to every listed customer.

Acquisition Report

Where the window's orders came from, rolled up server-side from each order's first-visit attribution: source (google, facebook, direct...), UTM campaign, orders, revenue, and how many were a customer's first order. unattributedOrders counts orders whose attribution was absent or still processing — attribution is eventually consistent upstream, so very recent orders often sit there for a while. This is per-ORDER attribution; session-level traffic and conversion rates come from shopify_analytics_query instead.

Analytics Query (ShopifyQL)

Run a ShopifyQL query against the store's analytics — the ONLY source for session and conversion metrics (the 'sessions' dataset carries conversion_rate, bounce_rate, added_to_cart_rate, traffic by referrer/UTM/device/geo). Grammar: FROM <dataset> SHOW <metrics> WHERE ... GROUP BY ... SINCE -7d UNTIL today ORDER BY ... LIMIT n. Exactly one FROM dataset per query; the dataset is validated against this token's permissions before anything is sent (finance datasets need the financials field, profitability needs inventory_costs). Needs the connected app to hold the read_reports scope — when it does not, accessInfo says so and names the derived report tools that work without it. Analytics data is not real-time: recent hours may be incomplete, so anchor daily figures to completed days.