What it takes to build a Shopify connector

Pulling orders out of Shopify is genuinely easy. An access token, a GraphQL query, and orders come back as JSON within an hour of starting.

That hour is what most estimates are based on, and it is why integration projects overrun. What follows is the rest of the work, in roughly the order it ambushes people.

The API you have to use

Shopify's Admin API is GraphQL. The REST Admin API has been legacy since October 2024, and new public apps have been required to use GraphQL exclusively since April 2025. Building against REST today means building against something already scheduled to disappear.

For teams used to REST this is a genuine adjustment. You describe the shape of what you want, nesting is normal, and the cost model punishes lazy queries.

Versioning is a subscription, not a purchase

Shopify ships a new API version every quarter — January, April, July, October — and supports each for roughly twelve months. When a breaking change affects you, there is a window of about nine months to migrate.

The practical consequence: an integration is never finished. Budget a maintenance pass two or three times a year, forever, or accept that the connector will silently break on a version you stopped tracking. This is the single most underestimated line in any integration plan.

Two approvals that are lead time, not paperwork

Orders older than 60 days. By default an app sees the last 60 days of orders. Anything further back requires an additional scope that Shopify must approve, requested through the Partner Dashboard with a written justification of why the app needs it.

For an ERP this is not optional. Historical migration, prior-year comparatives and any backfill all depend on it.

Protected customer data. Customer personal information requires separate approval, granted where the data requested is the minimum needed for the app to function.

Both take time and can come back with questions. They belong in the project plan at the start, not at the point where someone discovers the backfill returns nothing.

Rate limits are a cost model

Shopify does not count requests. It calculates a cost for each query and draws it from a bucket that refills at a fixed rate — roughly 100 points per second on standard plans, more on Advanced, considerably more on Plus and Enterprise. A single query can never exceed 1,000 points regardless of plan.

Two things follow.

Query shape matters more than query count. A greedy nested query fetching fields you do not need costs more and throttles you sooner.

Read the throttle status. Responses report the requested cost, the actual cost and the remaining capacity. Use those numbers rather than a hard-coded delay, because the limits differ by the merchant's plan and your connector does not control which plan they are on.

Bulk operations are the right tool for reconciliation

For a nightly full pull, ordinary paginated queries are the wrong mechanism. Shopify's bulk operations run asynchronously and return results as JSONL, and they sit outside the rate limits that constrain normal queries.

The trade is that they are asynchronous: you start a job, poll for completion, then download. That requires state — a job identifier, a status, a retry policy — which is more engineering than a synchronous loop, and it is what makes a nightly reconciliation feasible at all.

Webhooks, and why you cannot only use webhooks

Webhooks cover the event stream — order created, order paid, refund created — and steady-state operation should be webhook-driven.

They are not a complete solution on their own:

• Delivery is not guaranteed forever. Endpoints go down, and events are missed.
• Order matters and arrival order is not promised.
• Duplicates happen, so every handler must be idempotent — processing the same event twice must produce the same result as processing it once.

The workable design is webhooks for currency plus a periodic bulk reconcile to catch what was missed. Either alone is insufficient.

Then you do it all again for the gateway

This is the part that doubles the project, and it is invisible in any estimate that says "integrate with Shopify".

Because Shopify Payments is unavailable in Malaysia, Shopify holds no fee, settlement or payout data — see Shopify in Malaysia. The money side lives with iPay88 or eGHL under ADAPTIS, or Fiuu, Billplz, senangPay, Curlec or Stripe.

Each is a different company with a different API, different authentication, a different settlement file format, a different idea of what a payout record looks like, and different guarantees about when data is available. Some offer a modern API. Some offer a scheduled file. Both can work — see why integration depth beats feature count — but each is a separate build.

Supporting three gateways means three of these, plus the logic to tell which orders belong to which.

The state you have to keep

Underestimated more than anything else on this list. A connector that only fetches is not a connector; it is a script.

What has been seen, so nothing is processed twice. What has been matched, and on what basis, so a match can be explained later. What failed, and why, and how many times it has been retried. Which API version each stored record was fetched under, for when a field's meaning changes. The exceptions, in a form a person can work through.

That last one is the deliverable. Everything else exists so the exception list is short and trustworthy.

An honest estimate

The afternoon demo is real. So is this:

• Shopify authentication, scopes and the approval submissions
• GraphQL queries for orders, refunds, products, inventory
• Bulk operation orchestration with polling and retry
• Webhook receipt, verification, idempotency and replay
• One gateway integration, end to end
• Matching logic, exception handling and the review interface
• Accounting output that a bookkeeper agrees with
• Version-tracking and the recurring migration work

The last item never ends, which is the argument for buying rather than building — not that it cannot be built, but that it must be maintained by someone whose job that remains. See build versus buy for finance automation.

Common questions

Does a Shopify integration have to use GraphQL?

Effectively yes. The REST Admin API has been legacy since October 2024 and new public apps have been required to use GraphQL exclusively since April 2025, so a REST-based integration is built on a foundation already scheduled for removal.

How much ongoing maintenance does a Shopify connector need?

Shopify releases a new API version quarterly and supports each for around twelve months, with roughly nine months to migrate after a breaking change. That means two or three maintenance passes a year indefinitely, which is the cost most often left out of build-versus-buy comparisons.

What approvals are needed before an integration can work properly?

Access to orders older than 60 days requires an extra scope approved by Shopify with a written justification, and access to customer personal data requires a separate protected-data approval granted on a minimum-necessary basis. Both are needed for historical migration and both take time, so they belong at the start of a project plan.

Why does supporting a Malaysian store double the integration work?

Because Shopify Payments is unavailable in Malaysia, so Shopify carries no fee or payout data and the money side must come from the payment gateway. Each gateway is a separate company with its own API, authentication, settlement format and data guarantees, so every gateway supported is an additional integration alongside Shopify itself.

Related: how Shopify reconciliation actually works · build versus buy for finance automation · why integration depth beats feature count