Skip to content
All insights
Case study3 min readBy the DonDev team

ShipStation to monday.com order sync: Keeping the fulfillment board current

A fulfillment case study on syncing ShipStation updates to monday.com, with practical rules for split shipments, duplicate events and stale status.

Last updated

A parcel travels from a warehouse along an orange track to an operations ledger
On this page
  1. Give each system a clear job
  2. Map the cases people actually ask about
  3. Check for missed updates as well as duplicates

One box has shipped and another is still on the shelf. If the board simply says ‘shipped,’ customer support may tell the customer that everything is on the way. A status sync needs to preserve the difference between a shipment and an order.

In our ShipStation to monday.com project, Make and webhooks kept fulfillment status current on the operations board. The design checks below are useful when you want a board that people can rely on during busy shifts.

Key takeaways

  • Use stable order and shipment IDs.
  • Test partial shipments, duplicate events and missed updates.

Give each system a clear job

Let the shipping system own fulfillment facts and let the operations board own work assignments and notes. Update only the columns the integration owns. That keeps a routine status refresh from overwriting a handoff note someone added five minutes earlier.

Choose a stable key before wiring up the webhook. If the same order reference can occur in two stores, include the store in the key. Keep shipment IDs separately so several packages can roll up to the same order. Consult the ShipStation API documentation for the fields available in your integration.

Map the cases people actually ask about

Start with label created, partially shipped, shipped and needs review. Agree what each status means with operations and support. If a label is voided and replaced, the board should point to the current shipment rather than leaving people with a dead tracking link.

For a split order, store the individual shipment facts and derive the order-level status from them. Avoid a rule that sets the entire order to shipped as soon as any shipment event arrives.

Check for missed updates as well as duplicates

Design the update so receiving the same event twice does not create another board item. If events arrive out of order, compare against the current source record before letting an older update overwrite a newer one.

Run a periodic comparison over a recent window to catch records that failed to sync. Give someone ownership of the exceptions, such as an order with no matching board item. Test duplicate deliveries, a shipment void and an event deliberately skipped in staging.

A current board helps support answer where a parcel is. Finance still has to establish what was billed and paid. That separate problem is covered in our shipment reconciliation case study.

The takeaway

Make the board reflect shipping facts while preserving the notes and decisions your team owns.

The cover is an illustration. The example records and test scenarios are illustrative. How we write these guides.

Continue reading