Note: To respect confidentiality, the customer's name is intentionally omitted. The descriptions reference Shopify, Onfleet, and megaTrak only to explain the data flow.
Why this project exists
Operations were split across three platforms that did not talk to each other. Orders lived in Shopify, routes and assigned driver tasks lived in Onfleet, and inventory and fulfillment lived in their original inventory system. Every morning a person exported a CSV from Shopify and manually adjusted addresses and notes before uploading to Onfleet. A second round of exports had to be reconciled with inventory. Dynamisoft's flagship product, megaTrak, combined with the plugin removes the manual bridges and gives the team a single path from incoming order to assigned delivery.
Project snapshot
The integration runs daily and is also available on demand from the WMS UI. It pulls tagged Shopify orders and the related products, converts each order into an Onfleet task, and lets managers import driver assignments back into the WMS for routing and audit. The customer reports saving at least 90 minutes to 2 hours every day. Import and export errors have been rare over the last year and were linked to upstream issues rather than our processing. Since go live their daily order volume has about doubled and the flow has kept pace, including holiday peaks.
System overview
Shopify remains the system of record for e‑commerce orders. Our plugin runs inside the flagship WMS and uses the Shopify APIs to pull the day’s tagged orders and the required products. Parsed and validated data is stored in SQL Server and exposed to internal services through ASP.NET Core APIs. Orders are translated into Onfleet tasks through the Onfleet API. A manual action in the WMS pulls driver assignments back when dispatch is complete. Everything runs on the customer’s private network behind IIS.
Address normalization corrects common entry patterns from Shopify so Onfleet receives clear fields for street, unit, city, state, postal code, and country. The mapping is one task per order. We also persist the Shopify order id and the resulting Onfleet task id to keep the pipeline idempotent across retries.
Daily workflow
The day follows a short loop that keeps people out of spreadsheets.
-
Import tagged Shopify orders
Early each morning, Pacific time, the job pulls orders that carry the tags for fulfillment date and pickup or delivery. It also fetches the related products so the WMS has accurate item details.
-
Normalize addresses
The importer parses street, unit, city, state, postal code, and country using pattern rules and regular expressions. This resolves the common differences between how addresses are entered in Shopify and how Onfleet expects them.
-
Create Onfleet tasks
Each order becomes a single task. The task includes recipient name, phone, order number, delivery notes, address, and the pickup or delivery flag. Tasks are sent in batches to respect API limits.
-
Assign in Onfleet
Dispatchers use Onfleet to assign tasks to drivers. This step stays manual by design.
-
Import driver assignments
When assignments are ready, a button in the WMS pulls driver assignments back into the system for routing and audit.
Impact
The manual CSV ritual is gone. The team saves at least 90 minutes daily and often more on peak days. Address fixes that once took careful retyping are handled automatically. Errors are rare and traceable, and the customer's order volume has grown gracefully.
Engineering challenges and solutions
Shopify lookbacks and rate limits
Orders are selected by tags rather than creation date, which means the job must scan a moving window that can include older orders. The importer pages through Shopify with configurable lookback and batch sizes, and it resumes across pages without duplication.
Robust address parsing
I built a set of regular expression rules to split unit numbers and clean street lines, while keeping city, state, and postal code consistent. The parser handles common formats for apartment, suite, and unit so Onfleet receives a clean address every time.
Idempotency across retries
The system stores the Shopify order id and the created Onfleet task id. If a run is retriggered the importer skips completed work and only processes new or changed orders. This avoids double creation during manual reruns or partial failures.
Traceable integrations
We log Onfleet request and response pairs. Admins can review entries in our system's records to see what happened and to decide whether to rerun.
My role
I designed and built the plugin end to end, while my boss handled the development on the megaTrak WMS side, including the UI. My development work included the Shopify importer for orders and products, the address normalization, task creation for Onfleet, exporting Onfleet driver assignments, and the logging and diagnostics used by admins.
Tech stack and deployment
Frontend
Blazor Server in the flagship WMS
Backend
ASP.NET Core Web APIs inside the WMS, plugin logic hosted under IIS as a background service in a microservice
Data and Ops
SQL Server on premises, private network hosting, jobs surfaced in the WMS run queue
Extensibility
The importer and exporter are modular. New stores, tag conventions, or additional delivery services can be added without changing the WMS core logic. Shared logging and idempotency rules keep behavior consistent across providers.
Closing note
Thanks for reading. This integration focuses on practical wins: minimized manual labor and an automated data handoff between Shopify, Onfleet, and the WMS. If you would like to reach out to me, please use the contact form here.