The order exists in Magento. You can see it. The customer got a confirmation email. But it never showed up in ShipStation. Or it showed up twice. Or it arrived with the wrong weight, the wrong dimensions, and a shipping method that doesn’t map to anything real.
This is the gap. And if you’ve worked in e-commerce ops for any amount of time, you’ve lived in it.
Magento’s shipping integration problems are almost never a bug. They’re configuration drift — small mismatches that compound over time until something breaks visibly enough to notice.
Here’s where the problems actually live.
The Order Export Is Probably Fine. The Mapping Isn’t.
The most common thing I see: Magento is pushing orders to ShipStation correctly, but the shipping method names in Magento don’t match what ShipStation is expecting.
Magento stores shipping method codes like flatrate_flatrate or tablerate_bestway or whatever custom method you set up two years ago. ShipStation tries to read those and map them to a service. When it can’t, it either guesses or defaults — and the default is usually wrong.
The result: orders come in labeled “Other” or with a service that doesn’t match what the customer paid for. If you’re automating label creation, you’re printing the wrong labels and you might not know it until a customer calls.
What to check: In ShipStation, go to Settings → Shipping → Shipping Methods. Look at your mapped methods. If you see blanks, question marks, or “Other” for services that should be specific — that’s your problem.
Weight and Dimensions Are Being Ignored
Magento lets you set weight per product. Shipping platforms use that weight to calculate rates. This sounds simple and it is — until someone edits a product, imports a bulk CSV, or updates attributes and wipes the weight fields.
I’ve seen stores running for months with weight set to zero on half their catalog. Magento doesn’t throw an error. ShipStation doesn’t throw an error. It just calculates rates against nothing, defaults to some fallback value, and your shipping costs become fiction.
Same goes for dimensions if you’re using dimensional weight pricing — which FedEx and UPS both do above certain thresholds. If your products don’t have L x W x H set, you’re not getting accurate rate quotes. You’re getting estimates based on whatever default box size the platform assumes.
What to check: Pull a product export from Magento and filter for weight = 0 or null. Fix those before anything else.
Your Connection Is Degraded, Not Broken
A fully broken connection is easy to catch — nothing syncs, you notice immediately. The harder problem is a degraded connection.
This happens when Magento and ShipStation are technically connected but the handshake is slow, timing out occasionally, or hitting rate limits. Orders sync — just not all of them, and not consistently. Some come through in two minutes. Some take four hours. Some don’t come through at all and nobody notices until the customer emails.
The pattern usually looks like: “We keep having random orders that don’t show up right away.” That’s not random. That’s a connection that’s working well enough to not alert you but not well enough to be reliable.
What to check: Look at your order sync logs in ShipStation (Settings → Stores → your Magento store → View Log). If you see repeated timeouts, auth errors, or gaps in the sync timestamps, the connection needs attention — not a restart, attention.
Multi-Location Magento Adds a Layer
If you’re running Magento with multiple sources (MSI — Multi Source Inventory), the shipping integration gets more complex because the order has to resolve which source it’s fulfilling from before the right shipping logic can apply.
If your integration was set up before you added a second warehouse, it probably doesn’t know about it. Orders from that location may be routing through the wrong ship-from address, which means wrong rates, wrong pickup schedules, and potentially wrong carrier accounts.
This one tends to surface slowly — everything looks fine until you notice that orders from Location B are showing Location A’s rates, or labels are printing with the wrong return address.
What to check: If you added any sources or locations after your initial integration setup, assume the integration needs to be updated to account for them.
The Real Problem Is That Nobody Set It Up End-to-End
Most of the issues above come from the same root cause: the integration was connected but never fully configured. Someone got orders flowing and called it done.
“Connected” and “configured” are not the same thing.
A working integration means orders flow correctly, shipping methods map accurately, weights and dimensions are populated, rate sources are verified, and someone has actually checked the output against ground truth — not just assumed it’s right because nothing is obviously broken.
Getting there usually requires someone who’s actually worked inside both platforms, knows what the failure modes look like, and can read the logs without guessing.
Seeing orders fall through the gaps? Let’s figure out where. I’ve untangled a few of these and the answer is usually in the configuration, not the code.