The moment a dropshipping store takes a payment, a clock starts. Someone has to pass that order to the supplier, quickly and correctly, with the right address, the right product, the right quantity and any special instructions. In a small store a person does it by email or a supplier portal. As volume grows, the copying becomes a bottleneck and a source of error: an order forgotten on a busy afternoon, an address mistyped, a product sent to the wrong supplier, the same order sent twice. Each mistake costs money and a customer.
Order routing automates that step. This guide explains how to design it so that it is reliable: how to write routing rules, how to handle split orders and special cases, how to make sends safe to retry, how to bring tracking back and how to prove that nothing fell through. It is written for stores that work with one or many suppliers, including print-on-demand and marketplace models. It builds on the webhook and duplicate guidance in Shopify webhooks explained and the stock logic in inventory sync across sales channels.
The routing job, step by step
| Step | What happens | What can go wrong |
|---|---|---|
| 1. Detect | A paid order is noticed | The event is missed or arrives twice |
| 2. Validate | Address, items and payment are checked | Bad address, unmapped product |
| 3. Decide | Rules pick the supplier for each line | No rule matches, or two rules conflict |
| 4. Send | An order is placed with the supplier by API, email, file or portal | Timeout, rejection, duplicate |
| 5. Confirm | The supplier acknowledges with its own order number | No acknowledgement; silent failure |
| 6. Track | Tracking comes back and is applied to the store order | Tracking never arrives or is wrong |
| 7. Notify | The customer is told what is happening | Silence, or wrong information |
| 8. Reconcile | Daily comparison of store and supplier orders | Not done, so errors stay hidden |
Write the routing rules down
Before building anything, write in plain words how you decide where an item goes. Most stores have more rules than they realise, living in someone’s head. A short table makes them explicit and reveals gaps.
| Rule | Example | Question it answers |
|---|---|---|
| By product | All mugs go to supplier A; all posters to supplier B | Which supplier makes this? |
| By destination | EU orders go to the EU warehouse; US orders to the US one | Where is it cheapest and fastest? |
| By stock | Use supplier A if in stock, else supplier B | What if the preferred supplier cannot supply? |
| By price or margin | Choose the cheapest supplier that meets the delivery promise | Which option protects margin? |
| By speed | Express orders go to the supplier with next-day capability | What did the customer pay for? |
| By customer or value | High-value orders need extra checks first | Which orders need a person? |
| Fallback | If no rule matches, hold the order and alert a person | What if we have not planned for this? |
The last row matters most. A router that silently drops an order it does not understand is worse than a person. Every unmatched case should stop and ask.
Split orders and multi-supplier baskets
A basket containing items from two suppliers becomes two supplier orders and, usually, two parcels. Handle this explicitly. Route per line, create one supplier order per supplier, and keep a record that links each supplier order to the store order and its lines. Tell the customer at checkout, or at least in the confirmation, that items may arrive separately, and give an estimate for each. Decide how shipping is charged and how a partial refund works if only one parcel fails.
- Line-level mapping. Each order line carries the supplier it was sent to and the supplier’s order reference.
- Status per parcel. The store order’s fulfilment state follows each shipment, so that partial fulfilment is visible.
- Customer messages per parcel. Tracking and delay messages name the items in each parcel.
- Partial failure handling. If one supplier rejects, the other’s order stands, and a person decides about the missing items.
Sending safely: queues, keys and retries
The send step is where reliability is won or lost. Suppliers’ systems go down, rate limits apply, and networks fail. Three habits prevent most disasters.
| Habit | What it means | Why it matters |
|---|---|---|
| Queue the work | Put each routing job on a queue and process it at the supplier’s pace | A burst of orders does not overwhelm the supplier or lose jobs |
| Use a unique key | Build a key from the store order and line, and send it with the supplier order or store it to check first | A retry or a duplicate event never creates a second supplier order |
| Retry with growing delays | On failure, try again after a short wait, then longer | Brief outages heal without a person |
| Stop and alert after a limit | After several failures, move the job to a failed list and notify a person with the reason | Nothing fails silently |
| Keep a record of every attempt | Store what was sent, when, and the response | You can answer what happened to order 10482 |
Supplier connection types
| Method | How it works | Strength | Watch for |
|---|---|---|---|
| API | Your system calls the supplier’s system directly | Fast, confirmable, structured | Rate limits and changes to the API |
| Email order | A formatted email goes to the supplier | Works with any supplier | No confirmation unless they reply; parsing errors |
| File upload (CSV or FTP) | A file is placed on a schedule | Common for larger suppliers | Delays and file format mistakes |
| Supplier portal | Orders entered in a web form | Sometimes the only option | Needs a person or fragile automation |
The weaker the connection, the more checking you need around it. An email order should ask for acknowledgement, and your system should alert if none arrives within a set time. A file should be validated before it goes. A fragile portal integration should have the strongest monitoring of all.
Bringing tracking back
Routing is only half the job; the customer wants tracking. Collect it from each supplier in whatever form it arrives, match it to the store order and line and apply it so that the shipping notification goes out. Many suppliers are slow or inconsistent, so build expectations into the process: if no tracking appears within the supplier’s stated handling time, alert a person to chase. Use the tracking events afterwards for the delay alerts described in where is my order.
Reconcile every day
Even a good system loses an order now and then, for reasons nobody predicted. The control that makes the process trustworthy is a daily reconciliation. It lists every paid order from the last day or two and checks that each has a supplier order with an acknowledgement. It also lists every supplier order and checks that each has a paid store order. Differences are shown to a person with the reason, and the small ones can be fixed automatically.
| Check | Meaning if it fails | Action |
|---|---|---|
| Paid order with no supplier order | Missed event or failed send | Route it now; investigate the cause |
| Supplier order with no paid store order | Refunded or cancelled after sending, or a duplicate | Cancel with the supplier if possible |
| Supplier order unacknowledged after the expected time | Supplier did not receive it | Resend and alert |
| No tracking after the handling time | Supplier delay | Chase and tell the customer |
| Tracking not applied to the store order | Matching failure | Fix the mapping |
Special cases to plan for
- Address problems. Validate addresses before sending; a corrected address is cheaper than a returned parcel.
- Cancellations and changes. Decide how far an order can change after sending, and how to tell the supplier.
- Out-of-stock after payment. Have a rule: substitute, backorder or refund, and tell the customer promptly.
- Price changes. If the supplier’s cost rises after the sale, decide whether to absorb it or hold and review.
- Customs and regional rules. International orders may need extra data for duties; collect it at checkout.
- Returns. Know whether returns go to the supplier or to you, and how restocking and refunds work.
A worked example
A store sends about 150 orders a day, of which a third contain items from two suppliers. A person copies each into a portal or an email, taking about three minutes, which is 7.5 hours of work a day. Errors occur on roughly two percent of orders, about three a day, from typos, missed lines and orders sent twice, each costing around twenty dollars in refunds, reships and time. An automated router takes the human routing time to about one hour a day for exceptions, and the error rate drops to a handful a month. The time saved is more than six hours a day, and avoided errors are worth about $1,800 a month. The cost to build and test routing for several suppliers is a few thousand dollars, which pays back within a few months on these assumptions. The figures are illustrative, but the structure shows where the savings come from. For a build with these controls, see order routing to suppliers, and for platform-specific versions, CJ Dropshipping order routing and Etsy dropshipping automation.
A build checklist
- Write the routing rules and the fallback for unmatched cases.
- Decide the key that makes each supplier order unique.
- Choose the connection method for each supplier and the acknowledgement check.
- Design the queue, retry schedule and failed-job alert.
- Define how tracking is collected, matched and applied.
- Build the daily reconciliation and decide who reads its report.
- Test with real orders, including a split order, a failure, a duplicate event and a cancellation.
- Document the rules, the keys, the alerts and who owns each part.
Sources and further reading
Figures and rules in this guide come from the primary pages below. Platform limits and prices change, so open the page before you build on a number.
- Shopify developer docs: webhooks, how order events are delivered
- Shopify Help Center: fulfilment, fulfilment states and tracking
- Shopify Help Center: orders, order statuses and editing