Published
The short answer: three things inside ShipStation take out most of the avoidable cost — accurate dimensions on the product record, Rate Shopper choosing the service against live rates, and actually reading your carrier bill. Do those first. Three further problems sit outside what ShipStation’s automation rules can express, and they are worth knowing about only once the first three are done.
Most posts on this subject skip straight to what the platform cannot do. That is the wrong order, because for a lot of operations the first three settings are the whole saving and the rest is theory.
This is the highest-return hour in the account, and it is not a clever trick. Every rate you are ever quoted is calculated from the package on the order, so a wrong box is a wrong price, every time, in a direction you cannot see.
Set dimensions and weight on the product record and ShipStation applies them at import. Product Defaults apply to orders containing one line item at a quantity of one, which for most catalogues is most orders. Item-count rules cover part of the rest. Automating package dimensions covers both.
Do this before anything else. Everything below depends on it, and none of it works if the box is wrong.
If you are choosing carriers with static rules, this is the upgrade, and it is the single largest item on this page.
A static rule encodes a rate card as it stood on the day you wrote it. Rate Shopper queries live rates for the actual parcel and applies the winner, which matters because the cheapest service genuinely changes order to order:
Two settings do most of the work. Build the service collection wider than feels comfortable and let a transit time threshold decide what qualifies per order, rather than narrowing the pool in advance. And use Service Preferences to express a carrier preference, instead of giving away the comparison to protect one.
The first two are prospective. This one tells you whether they worked.
Summing label costs in a spreadsheet gives you what the labels cost when you bought them, not what the carrier charged after their facility measured the parcel. Adjustments arrive weeks later and cluster: one SKU with wrong dimensions, one lane picking up a surcharge nobody priced. Pulling your actual carrier bill out of ShipStation takes about five minutes and is the only way to see whether your dimensions are right.
If those three are done and the adjustments have stopped, you have taken most of what is available and the rest of this page may not apply to you.
Three problems the rules engine cannot express. All three need the actual contents of the order, which is not something a platform serving every kind of merchant holds.
This is the biggest of the three and the least known.
Carriers offer flat-rate and cubic programs: a fixed price if the order is packed into their box, regardless of weight within limits. These can beat standard weight-based rates substantially, but only if the order actually fits.
Rate Shopper does not reach this, and the reason is architectural rather than a setting you missed. ShipStation states it directly: “Rate Shopper only compares services. It does not compare different package types.” The box is an input to rating — their setup documentation requires the dimensions rule to run before the Rate Shopper rule — so by the time any rate is fetched, the packing decision is already made. If you packed into your own carton, the carrier’s flat-rate box was never eligible, whatever it would have cost.
You will not see these misses. Rate Shopper reports a win every time, because it correctly found the cheapest service for the box you handed it. There is no report line for the box nobody considered, and that is structural rather than a setting.
Audit first, and ask two questions rather than one. Take a sample of recent orders, pull the dimensions and weight, and check them against your carriers’ current flat-rate box sizes and price breaks. For each order: would the contents have fitted the box, and would the flat rate actually have been cheaper than what you paid?
Those are different tests and only the second one matters. An order can qualify for a flat-rate box and still be more expensive in it, which is the case people forget when they hear flat rate is cheap.
What you are looking for is a profile where the answer to both is yes most of the time. There usually is one, because flat rate wins on heavy orders going a long way — exactly where weight-based pricing hurts most. If you cannot find a profile where it wins most of the time, stop here. The rule below is not worth building and you have answered the question, which is worth knowing on its own.
Then write a rule for that profile. Once you can describe it — over N pounds, beyond zone N, under a certain item count — an automation rule can set the flat-rate service and package directly, and it will capture a good share of what the audit found without anyone touching an order.
Be clear about what that rule is. It is a blunt instrument, and it will be wrong in two directions:
That is still better than leaving the whole category unpriced. A rule that is directionally right on the heavy, far orders recovers most of an amount you are currently not recovering at all, and the failure mode is visible — a packer holding a box that does not work is a complaint you will hear about.
The version without those two failures has to price the standard rate and every eligible flat-rate option against the actual items, in one pass, and only then choose the box. That is packing and rating as a single decision rather than two, which is the logic we build alongside ShipStation.
Custom package presets are only as accurate as their match to your actual products, and catalogues drift as SKUs get added and packaging changes.
For a stable, narrow catalogue this is discipline rather than software: keep the presets current, review them when you add products, and periodically check whether the box chosen was the smallest that fits.
It stops being discipline when the right box depends on the combination of items rather than on any one product. That is cartonization, a computation over the item dimensions rather than a rule you can write down in advance.
Two categories ship in standard packaging when they should not. Temperature-sensitive items, where a box without insulation risks the order arriving spoiled, which costs a refund and a customer rather than a few cents of postage. And fragile or high-value items, where standard packaging raises the odds of damage.
A static rule catches the simple version: if the SKU is perishable, use the insulated box. It stops when the right answer depends on several variables at once — SKU and forecast temperature at the destination and transit time — because the rules engine reads fields already on the order and cannot call out for anything else.
Everything above is achievable inside ShipStation for straightforward cases: a narrow catalogue, one or two carriers, no perishables. It gets harder to maintain as complexity grows — more SKUs, more carriers, seasonal packaging, or decisions that need data the order does not carry.
At that point most operations do one of three things. Accept the inefficiency. Hire someone to review orders by hand. Or add a logic layer that runs these checks automatically on every order. That last one is the category String operates in — we build this kind of rate, packing and carrier logic into an existing ShipStation setup, without a migration to a full warehouse management system.
Is the cheapest advertised shipping rate always the actual cheapest option? No. Dimensional weight thresholds, zone banding and surcharges shift the real cost of a specific order, so the cheapest service changes order to order rather than being fixed by service level. That is what Rate Shopper is for: it queries live rates for the actual parcel and applies the winner, which no static rule can approximate reliably. If you are still choosing services with rules, turning it on is the largest single saving available to most accounts.
Does ShipStation automatically check flat-rate carrier programs against standard rates? No. ShipStation’s own documentation states that “Rate Shopper only compares services. It does not compare different package types.” It compares services for a package that has already been selected — its documentation requires the package dimensions rule to run before the Rate Shopper rule. Since flat-rate programs require packing into the carrier’s specific box, eligibility is decided upstream of rating, and a flat-rate option you didn’t pack into can’t win on price.
How much can flat-rate optimization actually save? It varies by product mix and order profile — bulkier, lighter items relative to their flat-rate box size tend to see the largest savings, since weight-based pricing would otherwise scale with dimensional weight. The only reliable way to know your number is auditing a sample of recent orders against current flat-rate price breaks.
Can I build cold-chain logic with standard ShipStation automation rules? Basic version, yes — a simple rule like “if SKU is perishable, use insulated box” can be set up directly. It gets harder once the decision depends on more than one variable at once, such as destination temperature at time of shipping, which native automation rules aren’t built to evaluate dynamically.
Why does my rate shopper never pick a flat rate box? Almost always because an automation rule set your package or dimensions before the Rate Shopper rule ran. Once the package is your own carton, the carrier’s flat-rate program is excluded by definition, regardless of price.
Knowing how a carrier prices a package is useful. The harder problem is making the right packing and rate decision on every order, when the correct answer changes with the contents, the destination and the rate card.
String builds and maintains that logic inside existing ShipStation accounts, for operations shipping roughly 6,000 orders a month or more. Below that, ShipStation's native automation and accurate product dimensions will get you most of the way there.
Eight patterns that show up when an operation needs custom shipping logic
