How much does a custom Shopify ERP integration cost in 2026?

A bespoke middleware integration to replace dropshipping apps typically costs around £15,000-£40,000. The exact price depends heavily on the supplier's API quality and whether you need complex bi-directional inventory syncing. The build usually takes 8-12 weeks.

When does custom middleware make sense vs dropshipping apps?

If your store processes fewer than 100 orders a day, stick with off-the-shelf apps like DSers or Zendrop. Custom middleware becomes necessary when you cross the £1M-£5M GMV band and start experiencing webhook timeouts, dropped orders, or inventory desyncs across multiple niche suppliers.

What is the difference between dropshipping apps and a hybrid 3PL?

Dropshipping apps route individual orders to suppliers who ship directly to the customer. A hybrid 3PL model involves buying bulk inventory for your top-selling SKUs and storing them locally for faster fulfilment, while using custom middleware to dropship only the long-tail catalogue.

Shopify Dropshipping at Scale: When DIY Apps Break (2026)

If you are scaling Shopify for dropshipping past 500 orders a day, DIY apps like DSers, Spocket, and Zendrop will eventually break your fulfilment flow. The failure is rarely the user interface; it is the underlying architecture. Once you hit high order concurrency, webhook delivery timeouts, rigid API rate limits, and asynchronous inventory states force you to choose between a hybrid 3PL model or building custom middleware.

Why Shopify dropshipping apps fail at high order volumes

When a merchant first installs a dropshipping app, the abstraction is clean. An order comes in, the app listens via a webhook, maps the SKU to an AliExpress or US supplier, and fires off a purchase order. But as volume scales, this abstraction leaks. Apps that work perfectly at 20 orders a day begin dropping events at 500.

The root cause is multi-tenant architecture. Most off-the-shelf dropshipping apps pool thousands of merchants onto a single infrastructure stack. When a major sales event occurs, the app's webhook ingestion servers get hammered. If the app's database locks or its external API calls to the supplier degrade, the entire queue backs up. You are no longer dealing with a simple data transfer; you are dealing with distributed system failure. Generic apps are built for the lowest common denominator. They use polling instead of event-driven architectures where possible, because it is cheaper to build. But polling introduces latency. If an app polls a supplier every hour, an item that goes out of stock at minute five will continue to be sold on your Shopify store for another 55 minutes.

For the engineer managing the store, the symptoms are frustratingly opaque. Orders appear in Shopify but never reach the supplier. Inventory levels drift out of sync. The dropshipping app's dashboard shows success, but the supplier's portal shows nothing. This happens because generic apps prioritise fast ingestion over guaranteed delivery, often failing to implement robust dead-letter queues or idempotent retry logic. When the app drops the payload, the merchant is left manually reconciling CSVs, completely defeating the purpose of automation.

Webhook delivery reliability and the dual inventory problem

The core architectural flaw in dropshipping is the dual truth problem. Shopify holds the frontend inventory truth, while the supplier holds the physical truth. The dropshipping app sits in the middle, relying entirely on asynchronous webhooks to keep the two states aligned.

Shopify automatically retries failed webhook deliveries using an exponential backoff schedule for up to 48 hours. If the dropshipping app's receiving endpoint is under load and fails to return a 200-series HTTP status code within 5 seconds, Shopify assumes the delivery failed and queues a retry. In a high-volume flash sale, these retries compound rapidly, creating a thundering herd effect that can take the app offline entirely.

By the time the app finally processes the delayed webhook, the supplier might have sold out of the variant. The result is a paid Shopify order that cannot be fulfilled. We typically see this failure mode peak during Black Friday or major influencer drops. The only reliable approach is to decouple ingestion from processing. Custom middleware achieves this by accepting the webhook immediately, storing the payload in a persistent queue like Amazon SQS or Google Cloud Pub/Sub, and processing the supplier API call asynchronously. Off-the-shelf apps rarely offer this level of isolation, leaving your store vulnerable to the app's shared infrastructure limits.

How GraphQL rate limits throttle bulk order synchronisation

Dropshipping apps must constantly poll suppliers and update Shopify's inventory to prevent overselling. However, Shopify's API strictly enforces rate limits to protect platform stability.

The Shopify GraphQL Admin API allocates a standard rate limit of 100 cost points per second. This operates on a leaky bucket algorithm. When a dropshipping app tries to update 5,000 variants across a shared merchant pool, it quickly hits this ceiling. The app must then pause its background jobs, leading to stale inventory data on the storefront. If a product goes out of stock at the supplier during this pause, Shopify will continue selling it.

Beyond rate limits, Shopify caps array pagination at 25,000 objects. Many generic apps fail to handle this pagination gracefully when executing bulk synchronisation tasks. Instead of cursor-based pagination with intelligent backoff, they attempt massive data pulls that timeout or return incomplete datasets. This leads to silent failures where new products simply do not sync to the storefront.

When you control the middleware, you control the API consumption. You can prioritise critical updates — like zeroing out out-of-stock items — over routine price adjustments, ensuring that your GraphQL point budget is spent where it matters most. You can also run bulk operations for massive inventory syncs, bypassing the standard point limits entirely.

The refund-loop logic trap in automated dropshipping

Order creation is only half the integration. The true test of a dropshipping architecture is how it handles state mutations, specifically cancellations and refunds. When a customer requests a cancellation on Shopify, does the dropshipping app successfully cancel the upstream purchase order? Usually, it does not.

If the supplier has already picked and packed the item, their ERP will reject the cancellation request. The dropshipping app, lacking a sophisticated state machine, often fails to relay this rejection back to Shopify. The merchant ends up refunding the customer on Shopify while still paying the supplier for the dispatched goods. Furthermore, managing the financial reconciliation of these split states becomes a nightmare for the accounting team.

We typically see a 15-25% increase in operational overhead just managing these edge-case refunds when relying on basic apps. You need custom middleware to enforce strict cancellation windows and synchronise refund states. When we deploy custom middleware — often replacing these apps with a direct Shopify NetSuite integration — we enforce strict state machines. If the supplier's ERP reports the order status as "processing", the middleware blocks the automated refund in Shopify and flags the order for manual review. This ensures that the physical reality of the warehouse matches the financial reality of the storefront.

Hybrid 3PL vs custom middleware: A 2026 decision matrix

When DIY apps break, merchants face a structural choice. Do you keep the dropshipping model but build custom infrastructure, or do you abandon pure dropshipping for a hybrid 3PL approach?

The Scaling Decision Matrix

Stay on DIY Apps (DSers / Spocket): Only viable if your annual GMV is under £1M and you process fewer than 100 orders a day. The manual reconciliation cost is lower than the engineering cost.
Build Custom Middleware: Makes sense for stores in the £1M-£5M GMV band that rely on 10+ niche suppliers. You maintain the cash flow benefits of dropshipping but eliminate the webhook failure modes.
Move to a Hybrid 3PL: The best path for stores above £5M GMV. You buy bulk inventory for your top 20% of SKUs and store them in a local 3PL, while using custom middleware to dropship the long-tail 80%.

For stores migrating off generic apps, evaluating Shopify Functions in production allows you to handle custom order routing natively, directing specific line items to the 3PL and others to the dropship supplier based on real-time inventory tags.

How to migrate from DSers to custom middleware in 5 steps

Moving away from a generic dropshipping app requires a careful cutover. You cannot afford to drop orders during the transition. Here is the procedural path we follow when replacing an app with a bespoke integration layer.

Export the legacy SKU mapping. Run your CSV export from the dropshipping app to capture the relationship between Shopify variant IDs and the supplier's internal SKUs. You need this mapping to route orders correctly.
Build the middleware ingestion layer. Set up a dedicated serverless function on AWS Lambda or Cloudflare Workers to receive Shopify orders/create webhooks. Ensure it responds with a 200 OK within 1 second to prevent Shopify retries.
Implement the supplier API integration. Write the logic to translate the Shopify order payload into the specific JSON or XML format required by your supplier's ERP, including the necessary authentication headers.
Deploy a custom inventory sync script. Use the GraphQL Admin API to run a scheduled job every 15 minutes, updating available inventory levels based on the supplier's real-time feed while respecting the 100 points per second limit.
Cut over and monitor the dead-letter queue. Disable the dropshipping app's order sync and route live traffic through your middleware. Monitor the queue for any payload validation errors or supplier API timeouts.

What to do next

If your dropshipping app is dropping orders, do not just install another app from the marketplace. You are simply trading one shared infrastructure bottleneck for another. Start by auditing your webhook logs in the Shopify Admin to see how many deliveries are failing or retrying.

Once you quantify the failure rate, evaluate the cost of lost orders against the cost of a custom build. A bespoke middleware integration typically takes 8-12 weeks and costs around £15,000-£40,000, depending on the complexity of your supplier's API. It pays for itself by eliminating manual order reconciliation, preventing overselling, and ensuring that every paid order actually reaches the warehouse. If you are serious about scaling dropshipping in 2026, you have to own the data pipeline.