Shopify API Documentation: A Practitioner

A hotel client came to us stuck inside an iframe. Their booking flow was a rigid, third-party widget bolted onto an otherwise beautiful site, no conversion tracking, no control over error states, no way to run more than one property without paying for another seat. When we started digging into how to replace it, the first thing we did was open the Shopify API documentation and the relevant PMS API references side by side, because the pattern for solving that problem, decoupling the frontend from the business logic, is the same pattern we use every time a client asks for something the platform does not give them out of the box.

That project is the spine of this guide. We are going to walk through how we actually read, navigate and build against Shopify’s APIs when we do custom app development for paying clients, not as a summary of Shopify’s docs (they can write those better than we can) but as the working knowledge our team has accumulated shipping this stuff.

TL;DR

• START WITH GRAPHQL, NOT REST: This is our position and we will defend it below. Shopify has effectively frozen the REST Admin API and moved all new functionality to GraphQL. If you are starting a custom app in 2026 and someone hands you REST endpoints, push back. We build new integrations on the GraphQL Admin API because that is where the rate limit model, the versioning and the future features actually live.
• THE DOCS ARE A MAP, NOT THE TERRITORY: The Shopify API documentation tells you what an endpoint returns. It does not tell you that a client’s ERP will export prices with the wrong VAT flag, or that the product export breaks on items with more than three variants. The gap between the docs and the real data is where 60 percent of the work lives.
• DECOUPLE THE FRONTEND FROM THE PLATFORM LOGIC: Whether it is a hotel booking engine or a Shopify storefront, the winning move is to talk to the platform at the API level and own the interface yourself. That is what gave our hotel client full UX control and GA4 conversion tracking their old system could never expose.

Step 1: Find the right Shopify API documentation before you write a line of code

The single most common reason a custom app project drifts over budget is that someone built against the wrong API. Shopify does not have one API. It has a family of them, and the Shopify API documentation is organised by which surface you are building for. Get this wrong and you will write three weeks of code against endpoints that cannot do what you need.

Here is how we orient a new build on the first call.

Where is the Shopify API documentation and which part do you actually need?

The canonical home is shopify.dev. Everything branches from there. The four surfaces we touch most often, and how we decide between them:

API surface	What it is for	When we reach for it
GraphQL Admin API	Reading and writing store data: products, orders, customers, inventory, fulfilment	Nearly every custom app and ERP integration we build
REST Admin API	The legacy version of the above	Only when maintaining an existing app or a library that has not moved yet
Storefront API	Headless and custom storefronts, reading products and managing carts client-side	Custom checkout flows, headless builds, embedded buy experiences
Ajax API and Theme extensions	In-theme interactivity without a full app	Small storefront tweaks where a full app is overkill

When the hotel booking engine work started, the equivalent decision was PMS-side: SiteMinder and the other property management systems each expose their own API, and we had to read three sets of docs to find the one that gave us live availability and rate data without a nightly batch delay. The Shopify version of that same triage is faster because it is one vendor, but the discipline is identical. Read the docs for every surface that could plausibly solve the problem before you commit to one.

How do I access Shopify API docs without getting lost?

The docs are dense. Our team bookmarks four specific pages rather than the landing page, because the landing page sends you in circles:

• The GraphQL Admin API reference, which has an in-browser explorer so you can run a query against a dev store before writing any app code.
• The API versioning page, because Shopify ships a new API version every quarter and deprecates old ones on a rolling schedule. If you do not know your version, you do not know your app.
• The rate limits page, which for GraphQL is a query-cost model, not a simple request count. More on this in Step 4, because it has surprised us on real projects.
• The webhooks reference, because most real integrations are event-driven, not polling.

Pro Tip: Before we scope any Shopify custom app, we spin up a free development store and run our three or four hardest queries in the GraphQL explorer on shopify.dev. On the Tehnodent build, a WooCommerce store rather than Shopify, the equivalent early check was pulling ten of their most variant-heavy dental products through the API to see what the ERP actually sent. It exposed a data-shape problem in the first afternoon that would have cost us a week if we had found it in staging.

Checkpoint: You have identified the exact API surface and API version your app targets, and you have run at least one real query or request against a dev store to confirm the data you need is actually exposed.

Checks we run before signing off Step 1:

• API surface: Confirmed which of the four Shopify APIs the feature needs, in writing.
• Version pinned: Chosen and recorded the API version, not left to default.
• Real query: Run the hardest read query against a dev store, not just read the docs.
• Data exists: Verified the specific fields the client needs are returned, not assumed.
• Rate model understood: Noted whether the surface uses cost-based or count-based limits.

Step 2: Set up authentication and a local build environment that mirrors production

The Shopify API documentation on authentication is accurate but it front-loads OAuth complexity that most builds do not need on day one. Our approach is to match the auth model to the app type, then build the environment so a developer can iterate without deploying to a live store every time.

Which app type and auth flow do you choose?

Shopify splits apps into a few types, and the authentication docs map cleanly onto them. Our decision rule:

App type	Auth model	We use it when
Custom app (single store)	Admin API access token from the Shopify admin	The integration is for one client’s store and will never be listed
Public app	OAuth flow, embedded in admin	The app will serve multiple merchants or be listed
Custom app via Shopify CLI	Token-based, dev-store first	Any serious build, because the CLI scaffolds versioning and local dev

For the vast majority of client work, a single-store custom app with an Admin API access token is the right answer, and it is far simpler than the OAuth dance the public-app docs describe. On the Ardon Adria engagement, the Croatian workwear and PPE supplier, we built a Shopify custom store with ERP and XML feed integrations, and the ERP-facing pieces authenticated with a scoped custom-app token. There was no reason to build a public OAuth app for one merchant. We see teams over-engineer this constantly because they read the public-app docs first and assume that is the default path. It is not.

Setting up the environment so you are not testing in production

The thing the docs will not stress enough: you need a development store that mirrors the client’s data shape, not an empty one. An empty dev store hides every problem that matters. We import a representative slice of the client’s catalogue, including the ugly products, the ones with fifteen variants, the ones with missing weights, the ones the ERP tagged wrong.

Pro Tip: On spec-driven B2B catalogues like Ardon Adria’s, where a product carries protection class, certification and a sizing matrix, we treat those specs as first-class API data, not as description text. When the product is bought on specifications, the specs are the interface. That decision drives how we model metafields, and it is the same principle we applied on the Metalne Police industrial storefronts. If you skip it, you get a fast build and a store nobody in the trade can actually buy from.

Checkpoint: You can authenticate against a dev store loaded with realistic client data and successfully make one authenticated write (create a product, update inventory, whatever the app does) without touching production.

Checks we run before signing off Step 2:

• Auth matched: App type and auth flow chosen deliberately, custom vs public justified.
• Scopes minimal: Requested only the access scopes the feature needs, no blanket permissions.
• Dev store realistic: Loaded with the client’s messy data, not a clean sample.
• Secrets handled: Tokens stored in environment config, never committed to the repo.
• One real write: Performed an authenticated write against the dev store successfully.

Step 3: Model the data before you build the integration

This is the step teams skip and the step that saves projects. The Shopify API documentation tells you the shape of a Product, a Variant, an InventoryLevel. It does not tell you how the client’s existing system disagrees with that shape. Modelling the data means sitting the two schemas next to each other and finding every place they conflict, before you write sync code.

What endpoints and objects are available in the Shopify API?

At a practical level, the objects you will spend most of your time with in the GraphQL Admin API are Product and ProductVariant, InventoryItem and InventoryLevel, Order and its line items, Customer, and Metafield. Fulfilment and Location objects come in the moment a client runs more than one warehouse. The GraphQL Admin API reference documents each with its fields and the mutations that write to them.

The interesting part is never the object list. It is the mapping. On Tehnodent, the dental equipment retailer, the WooCommerce store had to integrate with their ERP, and the ERP’s idea of a product did not match WooCommerce’s cleanly. The ERP exported prices with VAT handled differently than the storefront expected, and the variant structure for equipment with multiple configurations did not line up. We built the state-of-the-art store with ERP integration, and that store went on to increase their revenue by 80 percent, but the reason it worked was that we spent the first phase resolving those mapping conflicts rather than assuming the two systems agreed.

Here is the framework we use for that phase.

THE CLEAN HANDSHAKE FRAMEWORK

We call it the Clean Handshake because a data integration only works when both systems agree on exactly what a record means before any data crosses.

1. INVENTORY THE SOURCE: List every field the source system (ERP, PMS, legacy platform) actually exports, including the ones nobody documented. Pull real records, not the schema.
2. INVENTORY THE TARGET: List the Shopify (or platform) fields you can write to via the API, and their constraints, from the docs.
3. MAP AND FLAG CONFLICTS: Draw the field-to-field mapping and mark every conflict: VAT flags, units, encoding, variant limits, required fields with no source value.
4. DECIDE THE SOURCE OF TRUTH: For each conflicting field, decide which system wins and write it down. This one decision prevents most sync bugs.
5. BUILD THE TRANSFORM: Write the transform layer that resolves the conflicts, and test it against the ugliest 20 records first.

The hotel booking engine ran on the same framework, just with a PMS instead of an ERP. The source of truth for availability and rates had to be the PMS via SiteMinder, always, because a booking engine that shows a room the PMS has already sold is worse than no booking engine. Deciding that explicitly, in step four, is what let us build a fully branded frontend on top without ever risking a double booking.

Checkpoint: You have a written field-to-field mapping between the source system and the Shopify API objects, with every conflict flagged and a source-of-truth decision recorded for each one.

Checks we run before signing off Step 3:

• Real records inventoried: Source fields pulled from actual data, not the schema doc.
• Mapping documented: Every field mapped to a Shopify API field or explicitly dropped.
• Conflicts flagged: VAT, units, encoding and variant limits identified in writing.
• Source of truth set: One system named as authoritative for each contested field.
• Ugly records tested: Transform run against the twenty worst records before the happy path.

Step 4: Build against the GraphQL Admin API and respect the rate model

Now the code. This is where our position from the TL;DR earns its keep: we build new integrations on the GraphQL Admin API, and we treat the REST Admin API as legacy. Shopify has made this direction explicit, moving new functionality and eventually the bulk operations you need for large catalogues onto GraphQL. Building a new app on REST in 2026 is building on a surface the vendor is walking away from.

Why GraphQL, and why we disagree with the “REST is simpler” advice

Most guides tell you REST is simpler for beginners and you should start there. After doing this for clients, we think that is wrong for anything beyond a toy. REST feels simpler for one request and gets painful fast: you over-fetch data you do not need, you make N+1 requests to assemble a single product with its variants and metafields, and you hit the request-per-second wall on any real catalogue. GraphQL lets you ask for exactly the fields you need in one round trip, which matters enormously when you are syncing thousands of products.

The counterargument we respect: REST has more community examples and older libraries. That is real. But it is a decreasing advantage, and we would rather pay a small learning cost once than build a legacy integration on day one.

The rate limit surprise that cost us time

The GraphQL Admin API uses a calculated query cost model, not a simple request count. Each query has a cost based on the fields and connections you request, and you get a bucket that refills over time. Here is the honest admission: on an early large-catalogue sync, before we understood the model well, we wrote a query that pulled deeply nested variant and metafield data in one shot and kept hitting the throttle because the per-query cost was enormous even though we were making very few requests. We had scoped that sync at three weeks and it ran to five, largely because we had to rebuild the pagination and query structure to keep each query cheap and paginate wide rather than deep.

What we do now: we design queries to stay under a sensible cost ceiling, we read the `extensions.cost` field that Shopify returns on every response, and we use the bulk operations API for anything over a few thousand records rather than paginating manually. That single change turned a fragile sync into a boring, reliable one.

Task	Wrong approach we used once	What we do now
Full catalogue sync	Deep nested query, manual pagination, constant throttling	Bulk operations API, async, one job
Live inventory update	Poll all products on a timer	Webhook on inventory change, update only what moved
Order export	Fetch full order objects repeatedly	Query only changed orders since last cursor

Webhooks over polling, almost always

The other thing we learned the hard way: build event-driven. Polling the API on a timer wastes your rate budget and gives you stale data between polls. Shopify’s webhooks fire on the events you care about, order created, inventory updated, product changed, and you react to those. On the hotel booking engine, the whole architecture was event-driven at the PMS layer for exactly this reason: availability changes had to reflect immediately, and a polling delay would have shown wrong rooms.

Checkpoint: Your integration runs on GraphQL, reads the query cost off each response, uses bulk operations for large jobs, and reacts to webhooks rather than polling for anything time-sensitive.

Checks we run before signing off Step 4:

• GraphQL primary: New reads and writes on GraphQL, REST only for legacy maintenance.
• Cost monitored: Reading `extensions.cost` and staying under a defined ceiling.
• Bulk for scale: Anything over a few thousand records on bulk operations, not manual paging.
• Webhooks wired: Time-sensitive data driven by events, not timers.
• Retries handled: Backoff on throttle responses, not blind retry.

A booking engine that shows a room the PMS has already sold is worse than no booking engine at all.

Step 5: Decouple the frontend so you own the experience

This is the heart of the spine story and the strongest opinion in this guide. The reason the hotel client came to us was that their booking tool was an iframe. The third-party vendor owned the interface, the conversion flow, the error states and, critically, the analytics. The client could not see where in the flow people dropped off because the vendor’s iframe was a black box to GA4 and GTM.

We built a fully custom, fully branded booking engine that talks to SiteMinder and the other PMS systems at the API level. The PMS still owns availability, rates and the actual booking transaction, exactly as decided in the Clean Handshake. But the entire interface, the step-by-step flow, the instant feedback, the clear error states, was ours to design and instrument. That decoupling is what let the client run multiple locations from one custom-made booking engine, saving cost and time, because we adapt the same engine per property instead of rebuilding it each time.

Why the same principle applies to Shopify custom apps

The identical move works on Shopify. When a client needs a buying experience Shopify’s stock theme cannot give them, the answer is usually the Storefront API and a custom frontend, not a pile of theme hacks. You talk to Shopify’s platform logic (cart, checkout, inventory) through the API and own the presentation layer completely. This is the argument we make in our piece on why Shopify is more than just a platform: the value is not the theme, it is the reliable commerce engine underneath that you can build your own experience on top of.

What decoupling buys you that a locked-in tool cannot

The concrete wins, from the hotel engine and from Shopify storefront work:

• Full conversion tracking. Every step of a decoupled flow is a real page or component you can fire GA4 and GTM events on. Iframes and locked widgets cannot expose this, and you end up blind to where you lose customers.
• Real error handling. When the PMS or the Shopify API returns an error, you decide what the user sees, instead of a generic vendor message that kills trust.
• Reuse. A well-built decoupled engine is a product, not a one-off. We adapt ours per client. That is only possible because the logic and the interface are separate.

The tradeoff we accept honestly: decoupling costs more upfront than embedding a widget. You are building the frontend and the integration instead of pasting an iframe. For a single small store, a widget may be the right call. For a client running multiple locations or with real conversion ambition, the decoupled build pays for itself, which is exactly why the hotel client chose it.

Checkpoint: Your frontend renders and instruments every step of the flow independently, talks to the platform only through the API, and you can see a full conversion funnel in GA4 or your analytics of choice.

Checks we run before signing off Step 5:

• Interface owned: Presentation layer fully custom, no vendor-locked widget in the critical path.
• Analytics live: Every step fires a tracked event, funnel visible end to end.
• Error states designed: API errors mapped to clear, branded user messages.
• Logic in the platform: Cart, checkout, availability and transaction handled by the platform, not reimplemented.
• Reuse considered: Build structured so it can be adapted for the next client or location.

Get a decoupled build that actually converts

If you are staring at a locked-in booking tool, a checkout you cannot customise, or an ERP that will not talk to your store, this is exactly the work our ecommerce team does. Presta builds and integrates on Shopify, WooCommerce and Shopware, handles platform migrations, and builds custom apps against the Shopify API and third-party systems like the PMS and ERP integrations described throughout this guide. Talk to our team about your build. This is for operators who need real control over experience and data. It is not for someone who needs a one-page store live by Friday, an off-the-shelf theme will serve you better and cost less.

Step 6: Measure what the app was built to change

An integration or custom app is not done when it ships. It is done when you can prove it moved a number. We instrument from day one, and we agree the target metrics with the client before we write code, because retrofitting analytics onto a live app is painful and always incomplete.

The 30/60/90 day view

Here is how we structure measurement, built on what we actually track for the clients in this guide. The 30-day column is about technical health, 60 is about behaviour, 90 is about revenue.

Window	What we measure	Signal we want
30 days	Sync error rate, API throttle events, webhook delivery success, funnel event coverage	Integration is stable and every step is tracked
60 days	Step-by-step conversion, drop-off points, error-message frequency	Users completing the flow, drop-offs identified
90 days	Revenue, orders or bookings, cost saved vs the old tool	The number the project was justified on

On the hotel engine, the 90-day win was structural: running multiple locations from one engine, which shows up as cost and time saved rather than a single conversion percentage. On the Beberusha engagement, the Shopify baby and childcare retailer where we tweaked an existing store, the revenue signal arrived fast: revenue up 30 percent in the first month. That speed is only measurable because the events were instrumented properly, which is the whole point of Step 5. On Tehnodent, the 80 percent revenue increase is the kind of 90-day-plus number that a clean ERP integration and a real catalogue make possible, but you only see it if you tracked it from the start.

Pro Tip: We ask the client one question before building: “If this app works perfectly, which single number goes up?” On Beberusha it was revenue on an existing store. On the hotel engine it was cost of running multiple locations. Naming the one number prevents the vanity-metric drift where everyone celebrates API uptime while conversion quietly does nothing.

Checkpoint: You have a dashboard showing the 30-day technical metrics live now, and the 60 and 90-day behaviour and revenue metrics defined with a baseline recorded before launch.

Checks we run before signing off Step 6:

• One number named: The primary success metric agreed with the client in writing.
• Baseline captured: Pre-launch numbers recorded so you can prove change.
• Technical health tracked: Error rate, throttling and webhook delivery on a dashboard.
• Funnel instrumented: Every step of the flow emits an event.
• Review scheduled: 30, 60 and 90-day reviews on the calendar, not left to drift.

Common Mistakes

Mistake: Building the whole integration against the REST Admin API in 2026. Why It Happens: REST has more old tutorials and feels simpler for the first request, so teams start there without checking Shopify’s direction. Fix: Start on the GraphQL Admin API, use REST only to maintain existing code, and read the versioning page so you know what is being deprecated.

Mistake: Testing against an empty or clean development store. Why It Happens: A fresh dev store is fast to set up and every query works, which feels like progress. Fix: Load the client’s real, messy catalogue, including the variant-heavy and mis-tagged records, so the data-shape conflicts surface in week one, not in production.

Mistake: Polling the API on a timer instead of using webhooks. Why It Happens: Polling is conceptually simple and the docs make webhooks look like extra setup. Fix: Drive anything time-sensitive off webhooks, reserve polling for genuinely batch tasks, and watch your rate budget stop evaporating.

Advanced tips for teams already shipping against the Shopify API

Once the basics are solid, these are the moves that separate a fragile integration from one you can forget about.

Use bulk operations for everything at scale. The bulk operations API runs a large query asynchronously and hands you a file when it is done, which sidesteps the pagination and rate-limit pain entirely for full-catalogue jobs. We move any sync over a few thousand records onto it.

Pin your API version and diarise the upgrades. Shopify ships quarterly and deprecates on a schedule. We put the deprecation dates for our clients’ pinned versions in a shared calendar so an upgrade is planned work, not a 2 a.m. outage. If you are planning around the platform’s release cadence, our Shopify Winter 2026 rundown is the kind of forward view we keep for every client.

Model specs as structured metafields, not description text. On spec-driven catalogues, Ardon Adria’s PPE, Tehnodent’s dental equipment, the industrial storefronts, we push protection classes, certifications and sizing into typed metafields so they are queryable, filterable and API-addressable. Description-field specs are invisible to the API and useless for faceted search.

Treat the transform layer as the product. The Shopify objects and the source objects rarely change. The mapping between them is where all your business logic lives. We keep it isolated, tested and documented, because when the ERP changes an export format, and it will, you want to fix one layer, not hunt through the whole app.

If you are still weighing platforms before you commit to a custom build, it is worth reading our comparison of Shopify versus WooCommerce and, for teams currently on WooCommerce, our guide to the WooCommerce to Shopify move, because the right API to build against depends on which platform you land on.

Checks we run on a mature integration:

• Bulk for scale: All large syncs on the async bulk operations API.
• Version diarised: Deprecation dates tracked, upgrades planned as work.
• Specs structured: Buying-decision data in typed metafields, not free text.
• Transform isolated: Mapping logic in one tested, documented layer.
• Alerting live: Sync failures and throttle spikes trigger an alert, not a silent gap.

To close the loop on the hotel client: the decoupled, API-integrated booking engine replaced their iframe entirely, gave them the GA4 and GTM conversion tracking the old tool never could, and let them run multiple locations from one engine, saving cost and time. What would we do differently now? We would spend even longer in Step 3 on the source-of-truth decisions across the different PMS systems, because each one had its own quirks and we resolved some of them mid-build rather than up front. If you are just getting started, prioritise Steps 1 through 3: pick the right API surface, authenticate cleanly, and model the data before you write integration code, because every expensive surprise we have described lives in that gap between the docs and the real data. If you are auditing something that already exists, start at Step 4 and Step 6: check whether you are on GraphQL and whether you can actually see the conversion funnel, because those two answers tell you fast whether the build is future-proof and measurable.

Next Steps:

• Spin up a free Shopify development store and run your three hardest GraphQL queries in the explorer this week.
• Write the Clean Handshake mapping between your source system and the Shopify objects, flagging every VAT, unit and variant conflict.
• Name the single number the app must move, and record its baseline before you build anything.

Frequently Asked Questions

Where is the Shopify API documentation?

The official documentation lives at shopify.dev, and that is the only source we treat as authoritative. Everything branches from there: the GraphQL Admin API reference, the REST reference, the Storefront API, webhooks, authentication and the versioning schedule.

The practical advice we give clients is to bookmark the specific reference pages you use rather than the landing page, because the landing page is broad and sends you looking. The GraphQL Admin API reference with its in-browser explorer is the single most useful page for a custom app build, because you can test queries against a real dev store before writing a line of app code.

How do I access Shopify API docs and start testing quickly?

Go to shopify.dev, open the GraphQL Admin API reference, and use the GraphiQL explorer against a free development store. You create a development store from your Shopify Partners account at no cost. That combination, docs plus explorer plus dev store, lets you run real queries in minutes without setting up an app.

For anything serious, install the Shopify CLI, which scaffolds a custom app with versioning and local development handled for you. We use the CLI on every real build because it removes a class of setup mistakes, particularly around API versioning, that are tedious to debug later.

What endpoints are available in the Shopify API?

In the GraphQL Admin API, the objects you will use most are Product, ProductVariant, InventoryItem, InventoryLevel, Order, Customer, Fulfilment, Location and Metafield, each with its own queries for reading and mutations for writing. The Storefront API exposes a customer-facing subset focused on products, collections and cart. Webhooks fire on events like order creation, inventory change and product update.

The honest answer to “what is available” is: read the reference for the specific surface you are building on, because REST and GraphQL do not expose identical capabilities, and GraphQL is where new functionality lands. We have been caught out assuming a REST endpoint had a GraphQL equivalent when the reverse was true. Check the docs for your surface, do not assume parity.

Should I use the REST Admin API or the GraphQL Admin API?

GraphQL, for any new build. Shopify has frozen new development on REST and moved forward on GraphQL, including the bulk operations you need for large catalogues. Building new on REST in 2026 means building on a surface the vendor is deprecating.

The one exception is maintenance: if you are working on an existing app already built on REST, do not rewrite it purely for ideology. Migrate when you touch the relevant part, or when a feature you need only exists in GraphQL. For a greenfield app, though, the choice is not close.

How do the Shopify API rate limits actually work?

The GraphQL Admin API uses a calculated query cost model, not a request count. Every query has a cost based on the fields and connections you ask for, you get a bucket of points, and it refills over time. This surprised us on an early large sync: we made very few requests but each was so expensive it kept throttling.

The fix is to read the `extensions.cost` field Shopify returns on every response, design queries to stay cheap, paginate wide rather than deep, and move large jobs onto the asynchronous bulk operations API. The REST API uses a simpler leaky-bucket request count, but since we build on GraphQL, the cost model is what matters day to day.

Do I need a custom app, or can I do this with existing apps?

Start by checking the Shopify App Store. If an existing app solves your problem reliably, use it, a custom build is not free to make or maintain. We tell clients this plainly. The Beberusha result, revenue up 30 percent in the first month, came from tweaking an existing Shopify store, not from a bespoke app, because that was the right lever for that store.

You need a custom app when off-the-shelf apps cannot do it: a bespoke ERP integration, a decoupled frontend, a buying experience the platform does not offer, multiple locations run from one engine like our hotel client. The threshold is roughly this: if you are stacking three or four apps to fake one workflow, or paying per-seat for a locked tool you cannot instrument, a custom build usually wins on both control and cost within a year.

When does it make sense to bring in Presta’s ecommerce team?

Not every project needs an agency, and we will say so. If you have an in-house developer comfortable with GraphQL and your integration is straightforward, you may not need us. If your problem is a single existing app or a theme tweak, that is often a smaller job than hiring an agency implies.

It becomes worth bringing us in when the work crosses systems and stakes: an ERP or PMS integration where the data shapes disagree, a decoupled frontend that has to convert and be measurable, a platform migration, or a spec-driven B2B catalogue where the specs are the interface. That is the work we do across Shopify, WooCommerce, Shopware and, on the Ardon Adria build, nopCommerce. If you are weighing whether to hire help at all, our guide on how to evaluate a Shopify migration agency and our overview of Shopify agency services lay out honestly what an agency should and should not do for you. When you are ready, tell us what you are building.

How long does a custom Shopify API integration take to build?

It depends on the data, and specifically on how far the source system’s data shape sits from Shopify’s. In our scoping, a clean single-system integration with tidy data usually lands at a few weeks. An ERP integration where prices carry the wrong VAT flag and variants do not map cleanly, like the mapping work behind Tehnodent, runs longer because the transform layer is the real project.

We will be candid: we have scoped a large-catalogue sync at three weeks and had it run to five, because we underestimated the GraphQL rate-cost model on deeply nested queries and had to rebuild the query structure. Our rough estimate from past projects now includes explicit time for the Clean Handshake mapping phase, because pricing it in up front is far cheaper than discovering the conflicts in staging.

Sources

• Shopify Developer Documentation
• Shopify GraphQL Admin API reference
• Shopify API authentication and authorization
• Shopify API rate limits
• Shopify webhooks documentation
• Shopify bulk operations queries