Building a custom Shopify app: scopes, webhooks and rate limits done right

Many of the Shopify apps we build are never listed on the App Store. They are custom apps for a single merchant: syncing orders to a warehouse, generating wholesale price lists, calculating custom shipping or powering a product configurator. Because they run inside one business, it is tempting to treat them as scripts. That is how stores end up with an integration that works perfectly for eleven months and then drops two hundred orders during a holiday sale. These are the engineering practices we follow so private apps are as dependable as the platform they extend.

Scope the app like a product, not a script

Before writing code, we define what the app owns and what it deliberately does not. A warehouse sync app might own creating fulfilments and updating inventory, and explicitly not own order editing or customer data. That boundary drives three decisions:

• Access scopes. Request only what the app needs. An app with read_orders and write_fulfillments is far less risky than one with every scope enabled, and Shopify's protected customer data rules will require justification for anything touching personal information.
• Data storage. Store the minimum needed to do the job, and treat Shopify as the source of truth for everything else.
• Extension points. Decide early whether the app needs admin UI extensions, theme app extensions, checkout extensions or Shopify Functions, because each has its own deployment model.

Webhooks you can trust

Webhooks are how most custom apps learn that something happened. They are also the most common source of silent failures. Shopify delivers webhooks at least once, not exactly once, and not necessarily in order. Our baseline for every webhook handler:

1. Verify the HMAC signature on every request before doing anything else.
2. Respond quickly, well within Shopify's timeout, by writing the payload to a queue and returning a 200. Do the actual work in a background worker.
3. Make processing idempotent. Use the webhook ID or the resource ID and updated timestamp to detect duplicates, and design each operation so running it twice has no additional effect.
4. Handle ordering. Compare timestamps rather than assuming an update arrived after the create.
5. Reconcile regularly. Run a scheduled job that queries recent orders or products and catches anything a missed webhook left behind.

Webhooks tell you something probably happened. A reconciliation job tells you what actually did.

Reconciliation is the step teams most often skip. It is also the one that turns a missed webhook from an incident into a non-event. A job that runs every 15 minutes and checks the last hour of orders costs very little and has saved clients from several very awkward mornings.

Respecting rate limits

The GraphQL Admin API uses a cost-based rate limit: each query has a calculated cost, and each app has a bucket of points that refills over time. Plus stores get a larger bucket and faster refill, but no store has unlimited capacity. Apps that ignore this work in development and fail at scale.

The practices that keep us safely inside the limits:

• Request only the fields you need. Query cost scales with the number of fields and connections requested.
• Read the throttleStatus returned with every response and slow down before hitting zero, rather than retrying blindly after errors.
• Use bulk operations for large exports and imports. A bulk query for 50,000 products runs asynchronously and does not consume the interactive budget.
• Batch mutations where the API allows it, and spread scheduled jobs so they do not all fire at the top of the hour.

On a recent inventory sync handling roughly 12,000 SKUs across four locations, moving from per-variant REST calls to bulk operations and batched mutations cut a full sync from about 40 minutes to under five, with far fewer throttling errors.

Retries deserve the same care. When a call to Shopify or to a downstream system fails, the worker should retry with exponential backoff and jitter, give up after a bounded number of attempts and move the job to a dead-letter queue where someone can inspect it. A failed job should never disappear silently, and it should never retry forever while blocking everything behind it.

Deployment, monitoring and upgrades

We build custom apps with the Shopify CLI and app templates, keep the app configuration in version control, and deploy extensions and the app backend through CI rather than by hand. Every app gets structured logging, error tracking and an alert on queue depth, because a growing backlog is usually the first sign of trouble.

Shopify versions its APIs quarterly, and each version is supported for at least a year. We pin every app to a specific version and schedule an upgrade review each quarter as part of the client's care plan. Upgrading one version at a time is routine. Discovering that an app has fallen three versions behind the week before a deprecation is not.

Finally, we document the app for the merchant: what it does, what it does not do, where its logs live and who to call. Clients own the code outright, so that documentation matters if they ever bring the work in-house.

When to build rather than buy

Custom apps are not always the answer. If a well-maintained public app covers your needs, it is usually cheaper to use it. We recommend building when the logic is specific to your business, when public apps would require several subscriptions to approximate it, or when data flows into systems only you use. Our Shopify app development team builds these apps, often alongside Checkout Extensibility work or an ERP and inventory integration.

Have an app idea or a flaky integration?

Whether you need a new custom app or want an existing one made reliable, describe what it needs to do. We will reply within 24 hours with a fixed-price quote.