The setup

Army & Outdoors lists on eBay Australia and eBay USA via a Shopify app that handles the channel listings. When a customer buys something on eBay, the order flows into the relevant Shopify store as a normal order, and from there Cin7 Omni fetches it like any other order.

Same data, same flow, no visible difference in Cin7.

The problem

The customer service team wanted to prioritise eBay orders for processing and printing ? eBay buyers expect faster despatch and have specific feedback dynamics that make on-time fulfilment more valuable.

But Cin7 Omni had no native way to filter "show me only the orders that came from eBay." Once an order was in Cin7, it looked identical to a direct-from-Shopify order. The only way to know was to manually check each order's source ? not scalable when you're processing dozens of orders an hour.

Without filtering, eBay orders got processed in the same FIFO queue as everything else. Sometimes a 4-hour-old eBay order would sit behind 10 newer direct-Shopify orders just because the picker grabbed them in arrival order.

The solution ? webhook + cron + Cin7 update

Step 1 ? Catch the eBay orders at source

  • Created an orders/create webhook on the AU and USA Shopify stores
  • HMAC-verified, responds HTTP 200 immediately, then queues the work (the webhook reliability pattern I apply to every Shopify integration)
  • For each incoming order, the receiver checks whether the order originated from eBay (via the order's source/tags metadata)
  • If yes ? store in a MySQL queue with the order ID and timestamp
  • If no ? skip silently

Step 2 ? Wait for Cin7 to pick up the order

  • Cin7 doesn't fetch orders from Shopify instantly ? there's a delay of minutes to an hour depending on Cin7's polling cadence
  • A cron job runs continuously, checking for pending orders in the MySQL queue
  • For each pending order, it queries Cin7's API to see if the order has been imported yet
  • If Cin7 doesn't have the order yet ? skip this run, try again in the next cycle
  • If Cin7 has it ? move to step 3

Step 3 ? Tag the order in Cin7

  • The cron updates the Cin7 order, writing the text "ebay" into a free-text field on that order
  • The queue entry is marked complete so it doesn't get re-processed
  • Cin7 rate limits are respected ? batch size of 25 per run with exponential backoff on 429 responses

The result

In Cin7 Omni, the customer service team can now filter the order list by that "ebay" text ? eBay orders surface to the top of their queue. They print and despatch eBay orders first, then move on to the rest.

  • Zero manual filtering needed in Cin7 ? the tag is already there by the time they look
  • 2 stores tagged automatically ? AU and USA Shopify orders flow through the same pattern
  • Asynchronous + reliable ? handles Cin7's variable import lag without missing orders or double-tagging
  • Rate-limit aware ? won't blow through Cin7's API budget even on high-volume sale days

The technical bits worth noting

  • Two-stage pipeline ? webhook captures the intent, cron handles the timing. This is the right pattern when you depend on a third-party system that's not always immediately available. Trying to update Cin7 directly from the webhook would fail half the time because the order isn't there yet.
  • Idempotent updates ? if the cron processes the same queue entry twice (e.g., after a restart), it just writes the same "ebay" string. No harm done.
  • Free-text field used for filtering ? Cin7 doesn't have a native "tag" concept on orders the way Shopify does. Used a free-text field that's filterable in their order list view. Pragmatic, not pretty, but works reliably.
  • HMAC-verified webhooks ? every incoming Shopify webhook is verified before any work happens. No unauthenticated requests get to touch the queue.

Why this matters for your store

If you sell across multiple channels ? direct DTC plus marketplaces, plus B2B ? your fulfilment system probably can't tell them apart by default. Different channels have different SLAs, different packaging requirements, different expectations on speed.

The pattern here generalises: a small webhook + cron pipeline can enrich data in your downstream systems with information that makes operational decisions easier. eBay orders are one example. The same pattern works for "wholesale orders need different paperwork", or "marketplace returns route differently", or anything similar.

It's a few days of work to build, runs unattended for years, and frees the customer service team from manual sorting. I've shipped this exact pattern in production. I can do the equivalent for your stack.