Commerce integration guide
Shopify + UbiGrowth workflows
Shopify is a commerce platform that owns storefronts, orders, customers, and product catalogue data. This guide covers the records that matter, how the connection should be scoped, and what the first bounded workflow should be.
Introduction
Make Shopify part of the workflow, not another silo.
Validate connector availability for your workspace
This guide covers how a team designs a commerce workflow around Shopify with UbiGrowth: which records stay authoritative, how the connection should be scoped, what the first bounded workflow should be, and how to tell whether it worked.
The records that matter are Product, Variant, Order, Customer, Fulfillment, Inventory Level, and Refund. Shopify sells Variants, not Products, and inventory is tracked per Variant per Location. A workflow reasoning about a Product has no stock position to read.
Shopify is not currently on UbiVibe's verified connector list. This page is an implementation design reference: use it to specify the workflow, then validate whether the connection is available and correctly scoped for your workspace before you make it a dependency. The verified UbiVibe connections today are Salesforce, HubSpot, Gmail, Google Drive, Slack, and GitHub.
Grow is the usual destination for this connection, because the value shows up as outreach, reply handling, scheduling, and pipeline execution against the connected records.
Why teams evaluate this connection
Integrations create value when they remove operating friction.
The first design decision is not which API endpoint to call; it is which system owns the record, what event should trigger work, who owns the exception path, and what successful completion means.
Commerce platforms generate a continuous stream of events, and most merchants use almost none of it. Shopify records what was ordered and by whom, but the follow-up, retention, and service work that should follow from that record usually happens in a different tool with a different view of the customer.
The result is that the same customer is treated as new by marketing, as an order number by fulfilment, and as an unknown by support, which is exactly the experience that erodes repeat purchase rates.
You're likely here because
- Order data and customer follow-up live in separate tools
- Support answers order questions without order context
- Lifecycle campaigns run against stale exported segments
Record model
What a Shopify integration actually reads and writes.
Integration design starts from the objects the system really exposes, not from a generic connector diagram. These are Shopify's.
Identity and matching
Shopify sells Variants, not Products, and inventory is tracked per Variant per Location. A workflow reasoning about a Product has no stock position to read.
Start here
Read Orders held from fulfilment past the promised ship window and route them with the inventory position of the blocking Variant.
What this will not do
It will not reconcile finance. Shopify Payments payouts net fees and refunds; the ledger position needs the payout report, not the order total.
The constraint to plan around
The Admin API is throttled on a leaky-bucket basis and bulk reads must go through the bulk operations endpoint, so a naive full-catalogue sync is rate-limited rather than slow.
Build notes
What you actually have to reason about in Shopify.
The fields that carry meaning, how the connection authenticates, and whether the event surface can be trusted. This is the part that decides whether the integration works in month three.
| Field | Why it matters |
|---|---|
| variant id | the sellable unit; a Product has no stock position of its own |
| inventory_item_id / location_id | stock is tracked per variant per location, so a single quantity is a sum |
| financial_status vs fulfillment_status | paid and shipped are independent, and conflating them misreports the order |
| line_item id | refunds and fulfilments reference lines rather than the order |
| updated_at | the incremental cursor, with cursor-based pagination required at volume |
Authentication
Custom app with an Admin API access token scoped per resource, installed on the shop. Protected customer data requires an additional approval step, which teams discover after building the customer-facing part.
Events and delivery
Webhooks with HMAC verification, delivered at-least-once with retries, and Shopify removes a webhook that fails persistently. Bulk operations exist for large reads because pagination at catalogue scale is otherwise impractical.
Workflow
How the Shopify workflow runs.
The operating sequence, from reading the source system through to the result landing back where it belongs.
Step 01
Read order and customer state
Connected Shopify data provides the real order, customer, and fulfilment state rather than a periodic export.
Step 02
Resolve the customer
The customer is matched across order, marketing, and support systems using a defined rule, including the ambiguous case.
Step 03
Trigger from a real event
Follow-up is driven by an actual order or fulfilment event, so the message matches the customer experience.
Step 04
Run the lifecycle action
Post-purchase, exception, or repeat-purchase follow-up runs with the product and timing context attached, under review while it is being proven.
Design decisions
The commerce decisions this connection forces.
Each of these has to be settled before the Shopify workflow is allowed to write anything.
Step 01
Resolve the customer across channels
Decide how a customer in Shopify is matched to the same person in marketing, support, and any other channel, including what happens when the match is ambiguous.
Step 02
Treat order state as the trigger
Follow-up should be driven by real order and fulfilment state rather than by a periodic export, otherwise the message and the customer experience diverge.
Implementation path
How to implement the Shopify workflow.
- 01
Decide which records Shopify owns and which the workflow may act on, starting read-only.
- 02
Define the customer identity match across order, marketing, and support systems before enabling any follow-up.
- 03
Pick one lifecycle moment — post-purchase, fulfilment exception, or repeat-purchase timing — and instrument only that.
- 04
Once fulfilment delays are routed, add the upstream view: which products or suppliers cause them, so the fix is procurement rather than apology.
Governance
Controls that matter.
Control 01
Order, refund, and fulfilment changes require explicit authorization rather than automated convenience.
Control 02
Customer messaging honours consent, preference, and channel rules.
Control 03
Payment and personal data stay in the systems that already govern them, at scoped access.
Failure modes
How a Shopify integration breaks in production.
Not generic integration advice. These follow from how this system actually behaves, which is why they look nothing like the list on the next guide over.
Symptom 01
The store oversells stock it does not have.
Cause
Inventory was set to an absolute quantity, overwriting concurrent sales.
Fix
Use inventory adjustments rather than absolute sets, so concurrent changes compose.
Symptom 02
A webhook is removed by Shopify without notice.
Cause
It failed persistently and was automatically deleted.
Fix
Monitor webhook registrations and re-register, treating disappearance as an expected failure mode.
Symptom 03
Financial reporting does not match the bank.
Cause
Order totals were used rather than payout data, which nets fees and refunds.
Fix
Reconcile against the payout report.
What changes at scale
The Admin API uses a leaky-bucket limit with cost per query on GraphQL. Bulk operations exist for catalogue-scale reads and are the only viable path above a few thousand records.
Examples
What a working Shopify workflow looks like.
Bounded scenarios rather than a feature list. Each one can be verified against work the team already does.
Customer lifecycle
With Shopify connected, follow-up runs against real order and customer state rather than a segment exported last month.
Post-purchase lifecycle
A specific order event in Shopify triggers follow-up with the product and timing context attached, instead of a generic scheduled campaign.
Limitations and considerations
What to validate before you depend on this.
- The Admin API is throttled on a leaky-bucket basis and bulk reads must go through the bulk operations endpoint, so a naive full-catalogue sync is rate-limited rather than slow.
- Inventory writes affect what customers can buy within seconds. Setting an absolute quantity rather than an adjustment overwrites concurrent sales, and the store then oversells stock it does not have.
- When financial reconciliation is the goal. Shopify Payments payouts net fees and refunds, so the ledger position needs the payout report rather than order totals.
- Marketplace and platform policies constrain what can be automated around Shopify, particularly for customer contact; check the rules before designing the workflow.
- Order, refund, and fulfilment writes carry direct customer and financial consequences and need explicit authorization.
FAQ
Shopify integration questions.
What records does a Shopify integration actually work with?
The primary records are Product, Variant, Order, Customer, Fulfillment, Inventory Level, and Refund. Shopify sells Variants, not Products, and inventory is tracked per Variant per Location. A workflow reasoning about a Product has no stock position to read.
What should the first Shopify workflow be?
Read Orders held from fulfilment past the promised ship window and route them with the inventory position of the blocking Variant.
What will a Shopify integration not do?
It will not reconcile finance. Shopify Payments payouts net fees and refunds; the ledger position needs the payout report, not the order total.
What is the main constraint to plan around?
The Admin API is throttled on a leaky-bucket basis and bulk reads must go through the bulk operations endpoint, so a naive full-catalogue sync is rate-limited rather than slow.
What changes about a Shopify integration at scale?
The Admin API uses a leaky-bucket limit with cost per query on GraphQL. Bulk operations exist for catalogue-scale reads and are the only viable path above a few thousand records.
How does authentication work for Shopify?
Custom app with an Admin API access token scoped per resource, installed on the shop. Protected customer data requires an additional approval step, which teams discover after building the customer-facing part.
Does Shopify support webhooks, and can they be trusted?
Webhooks with HMAC verification, delivered at-least-once with retries, and Shopify removes a webhook that fails persistently. Bulk operations exist for large reads because pagination at catalogue scale is otherwise impractical.
What is the risk of writing to Shopify?
Inventory writes affect what customers can buy within seconds. Setting an absolute quantity rather than an adjustment overwrites concurrent sales, and the store then oversells stock it does not have.
When is connecting Shopify the wrong call?
When financial reconciliation is the goal. Shopify Payments payouts net fees and refunds, so the ledger position needs the payout report rather than order totals.
What should a Shopify integration automate first?
Start with one bounded workflow that removes a measurable handoff, duplicate-entry step, reporting delay, or follow-up gap. Expand only after the first workflow is reliable.
Does UbiGrowth require Shopify to be replaced?
No. The operating model is designed around connecting to systems that should remain authoritative and building workflows around them rather than forcing a wholesale replacement.
Is connector availability identical for every workspace?
No. Availability can depend on provider configuration, authentication, scopes, workspace setup, and deployment state. Validate the required connection before treating it as an operational dependency.
Can follow-up be triggered by Shopify order events?
Yes, and it should be. Follow-up driven by real order and fulfilment state is materially more accurate than a periodic exported segment.
Can the workflow change orders or issue refunds?
Those actions carry direct customer and financial consequences and require explicit human authorization rather than automated convenience.
How is the same customer recognised across channels?
Through an identity match rule you define, including what happens when a match is ambiguous. Resolution is rarely perfect, so design for the ambiguous case.
How this access is governed
What ARIA is allowed to do in Shopify, and who decides.
Connecting Shopify is a permission decision, not just a setup step. These are the controls that decide what ARIA can reach, what it can change, what gets recorded, and how you take the access back.
Required permissions
ARIA works through the scopes the connection was granted, and no others. Authorization happens at the provider, so the permissions being requested are shown by the system itself before anything is connected.
What it can reach
Reachable systems are the intersection of what your organization approved in the connector registry and what the requesting identity is permitted to use. Identity resolves before execution, not after.
What it can do
Actions run through explicit execution paths with state, spend, and failure boundaries — a bounded worker path rather than an open-ended agent loop with a credential.
Credential handling
Credentials live in the governed connection layer and are resolved through canonical connection identity. They are not pasted into individual workflows, prompts, or generated artifacts.
Action logging
Execution carries state and traces: what triggered the work, which connection it used, and what came back — including an explicit failure when something did not run.
Approval and revocation
Consequential actions can be made to require a person to approve them. Access can be changed or revoked at the connection, and ARIA loses that reach without unpicking the work already completed.
Start with ARIA
Ask ARIA to run this integration.
Describe the outcome you need across this system. ARIA works out the scopes, data, and actions the job requires, and operates inside the access you grant — which you can change or revoke.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Turn the integration into a working business outcome.
Start with ARIA to describe the outcome, then continue into the product path that fits the workflow. Connector availability and required scopes should be validated for the specific workspace before production use.