The ShipStation Configuration Guide: Every Layer, in the Order to Set It Up
Almost every ShipStation operation should be configured close to the same way. The variance between accounts is real but it is smaller than people expect, and it sits at the end rather than throughout. Most of what separates a well-configured account from a badly-configured one is not nuance — it is layers nobody set up.
This page is the complete configuration in the order to do it, with a link to the full explanation at each step. It follows ShipStation's own documented sequence, because that is what makes the order non-arbitrary: each layer can override everything above it and none can un-override, so the rule is to put a decision in the earliest layer that can express it correctly.
If your question is what a given capability does and where it stops rather than when to set it up, the ShipStation automation guide answers that instead.
Two orders, not one
Worth being precise about this before the list, because it is the one place a setup order and ShipStation's documentation diverge. ShipStation documents a runtime sequence — Auto-Routing, Auto-Split, Preset Groups, Product Defaults, Service Mapping, then Automation Rules — which is the order those layers execute in when an order imports.
Carrier accounts, packages, product data and tags are not in that sequence, because they do not execute. They are the settings and catalogue data the layers read. So the order below is: the data first, then the layers in ShipStation's documented order. Sections 1 to 4 are things you populate. Sections 5 to 12 are things that run.
What the layers read
None of this is in ShipStation's runtime sequence, because none of it executes. These are the settings and catalogue data every layer below reads, and they are first for that reason rather than because the platform runs them first. An automation layer can only be as good as the data it was handed.
1. Carrier accounts
What to set. Connect the carrier accounts you actually ship on, and know which one is primary. Decide whether ShipStation Carriers stays enabled alongside your own accounts. If you run two accounts on the same carrier, note which services each one offers.
Why it belongs here. Every layer below this eventually names a shipping service, and a service belongs to an account. Deciding this later means rewriting the rules that name services.
What breaks without it. With two accounts on one carrier, the Charge Shipping to My Account action clears the order's shipping service when the selected account does not offer it. Orders reach the packing bench with no service on them and nothing warns you. Where that rule sits in the list is the whole decision.
Can I run two accounts with the same carrier in ShipStation, and how do orders get to the second one?
Yes, on carriers that support it. Connect both accounts and the first one becomes the primary — ShipStation states it always defaults to the primary account for a carrier when you select a carrier service. To send an order to the other account, change the Shipping Account in Other Shipping Options on the order, apply it to a selection in bulk, or set it at import with the Charge Shipping to My Account automation rule action.
Three things always use the primary account regardless of what you configure: return labels, labels created directly in the Rate Calculator, and any service picked from a list sorted by carrier rather than by account. Not all carriers allow multiple accounts, and ShipStation recommends giving each one a unique nickname so they are distinguishable in the service menu.
2. Packages
What to set. Add every box you actually stock as a custom package, with its real internal dimensions. Not the outer dimensions, and not the dimensions on the supplier's invoice. Include mailers and envelopes.
Why it belongs here. Every later layer that sets a box picks from this list. A rule cannot apply a package that does not exist, and a packing calculation cannot pack into one it has never been told about.
What breaks without it. Two things, and they are different. Wrong dimensions produce rates quoted against a box you are not shipping, which surfaces as carrier adjustments weeks later. A missing box means the rules quietly use the nearest one you did add, which is usually bigger.
Should I use carrier packaging or my own boxes in ShipStation?
Default to your own, and use carrier packaging on the services that require it to give you their rate. Selecting a carrier's flat-rate package is a declaration, not a note about what you packed: it is how the carrier learns the box is theirs, and entering the same dimensions by hand does not do it.
Only the second job changes how the parcel is rated. The carrier prices from the weight and dimensions it is sent, so a saved custom package rates exactly as the generic Package entry does — the value of a package list is accurate dimensions, and separately, box sizes small enough to keep parcels out of dimensional weight. Rate Shopper will not tell you which was cheaper: it compares the rates carriers return for different services, never different packages, so the box is the one input it never varies.
3. Product data
What to set. A weight and a set of dimensions on every product record. This is data entry rather than configuration, and it is the item most often skipped for that reason.
Why it belongs here. Preset Groups, Product Defaults and SmartFill all read the product record, and everything downstream of them inherits whatever they wrote. This is the earliest layer that can express a fact about a product correctly, which is exactly why the fact belongs here rather than in a rule restating it.
What breaks without it. Everything below degrades quietly rather than failing. Rate Shopper prices whatever box it was handed, so an accurate comparison against wrong dimensions returns a confident wrong answer. Packing Recommendations will not run at all without per-SKU dimensions. Cartonization is not possible in any form. Nothing errors, and the cost arrives as carrier adjustments and oversized parcels.
Where does ShipStation get an order's weight from?
From five places, which override each other in a fixed order: the weight the marketplace sent, SmartFill, Product Defaults or a Preset Group, an automation rule, and finally whatever a connected scale or a person types at the shipment screen. SmartFill runs after Auto-Split and before every other kind of automation, so anything below it wins.
The one worth knowing about is SmartFill, because it is on by default and it is not a rule you wrote. It copies weight and dimensions from the two most recent labels for the exact same combination of items, and only when those two agree. Product Defaults are also unusual here: they normally require a single-item order, and weight is the documented exception that applies anyway.
Where Order Weights Come From in ShipStation, and Why Yours Are Probably Round →
4. Tags
What to set. A small set of tags describing what a product or customer is — fragile, dry ice, drop-ship, pre-order, VIP, wholesale. Apply them to the product and customer records, not to orders. The product CSV carries Tags and Tag1 to Tag5 columns, which is how you keep up at catalogue scale.
Why it belongs here. ShipStation applies product and customer tags to orders at import, before any other automation runs. That timing is the whole value: every layer below can key on them. It is also the only product-record field besides weight and customs that survives a multi-item order.
What breaks without it. A new SKU with no tags falls through every rule keyed to them, silently, with no unmatched-order queue to catch it. Tags applied to a product record also never reach orders that already imported, so a correction is never retroactive.
Where do ShipStation tags come from?
Three places, landing at different moments. Product tags and customer tags are applied to the order at import — ShipStation states they arrive before any other automation applies — so every rule that runs afterwards can read them. Rule-applied tags are added by an automation rule and are only visible to rules below it in the list. You can also apply tags by hand from the Orders grid or Order Details.
The timing is the whole reason tags are useful. A product tag is on the order before Preset Groups, Product Defaults, Service Mapping or any rule has run, so it is available as criteria to all of them.
What runs before everything else
ShipStation documents Auto-Routing and Auto-Split as positions one and two of its automation sequence. Both are plan-gated, so many accounts have neither, but they are worth checking for before you build anything below — they run first, and Auto-Split in particular changes what every later layer sees.
5. Auto-Routing
What to set. If your account has it, configure which warehouses stock which products. Auto-Routing then assigns a ship-from location per order based on stock and proximity. Check first: ShipStation documents it as US and Canada accounts on the High Volume plan.
Why it belongs here. It is documented as the first thing that runs. Which warehouse fulfils an order is a fact about stock and geography, settled before anything about the parcel — and the ship-from location changes the rate every later layer is working towards.
What breaks without it. Without it, ship-from is whatever your default warehouse is, and multi-warehouse operations pay for the distance. Note also that it does not apply to manual orders, so anything keyed in by hand skips it.
Can ShipStation choose which warehouse fulfills an order?
Yes. Auto-Routing determines fulfillment based on which warehouses stock the items and which is closest to the recipient. Available for US and Canada accounts on the High Volume plan.
You can also set Ship From Location per store with a basic rule, if your routing logic is simply 'Shopify orders ship from the main warehouse.'
6. Auto-Split, and the SmartFill you did not configure
What to set. Auto-Split is set per product, on the product's Shipping tab: Exclusive Bulk Shipping, Ships Individually, or Ship on Custom Quantity. Configure it only where the split is genuinely a property of the product. Also plan-gated, and it does not apply to manual orders.
Why it belongs here. It runs second, before every other kind of automation, so the shipments it creates are what the rest of the sequence operates on. It executes a decision you declared on the product record in advance rather than working anything out per order.
What breaks without it. Two things worth knowing even if you never enable it. Split shipments do not inherit tags from the original shipment, so a tag applied at import is not on the pieces a split creates. And sitting between Auto-Split and everything below is SmartFill, which is on by default and which nobody configures: it copies weight and dimensions from your own two most recent shipments of the same item combination, and only when those two agree. It is designed to lose every argument with the layers below, so it is never why a value is wrong — it is why a value exists at all on orders nothing else touched.
Can ShipStation split orders into separate shipments automatically?
Yes, when the rule is a property of the product. Auto-Split creates separate shipments based on settings you configure per product: Exclusive Bulk Shipping, Ships Individually, or Ship on Custom Quantity.
Exactly right for an oversized item that always ships alone, or products that ship a fixed number to a box. Plan-gated (High Volume for US/Canada/ANZ, Enterprise for UK/EU, or an add-on) and doesn't apply to manual orders.
Can ShipStation Split an Order Across Multiple Boxes Automatically? →
The documented sequence
From here the order is ShipStation's own, and each layer can override everything above it. That is what makes the sequence worth following rather than arbitrary: a decision placed too late is invisible to everything that needed it, and a decision placed too early gets quietly overwritten by something you forgot you wrote.
7. Preset Groups, and Product Defaults
What to set. Two versions of the same idea, so set them together. A Preset Group holds shipment and customs values shared across a category of products. Product Defaults hold the same kinds of facts for one product. Put a value on the group where it is true of the category, and on the product only where it is not.
Why it belongs here. Both are product-shaped facts, and a product-shaped fact does not belong in a rule. On the product record it needs no criteria, cannot get out of sequence, and does not add a row to a list somebody has to reason about in a year. The instinct to put everything in rules is what produces the fifty-rule account, and a good share of those rules are restating facts about products.
What breaks without it. Product Defaults apply only to an order containing a single line item at a quantity of one, and weight is the documented exception that applies anyway. So a product-level box size never reaches a mixed basket, while a product-level weight does. Setting dimensions here and assuming they cover your multi-item orders is one of the most common misreadings of the platform.
What is the difference between a Preset Group and a Shipping Preset?
A Product Preset Group is a shared product default. Assign products to it and its shipping service, package, weight, dimensions and customs values apply automatically at import, unless an individual Product Default overrides them. A Shipping Preset is a manual shortcut applied at the shipment screen by hotkey or by scanning a barcode.
Use a Preset Group when the answer is a property of the product, and a Shipping Preset when a person genuinely has to look at the parcel — presets carry hotkeys and print as scannable barcodes. If you want a rule to apply a saved combination, the mechanism is a Shipping Strategy rather than a preset: ShipStation states you cannot use automation to apply presets, but Set Shipping Strategy is a standard rule action.
8. Service Mapping
What to set. Map each shipping option your checkout offers to the carrier service that fulfils it. Do this for every store, and revisit it whenever the checkout options change.
Why it belongs here. It is the only layer that knows what the customer was promised. It runs before automation rules, which means Requested Service (Mapped) is populated by the time rules evaluate and can be used as criteria — including to route an order to the right Rate Shopper configuration.
What breaks without it. An unmapped option means the choice the customer paid for does not reach fulfilment, and somebody at the bench guesses. The failure is invisible from inside ShipStation because the order looks complete.
Can ShipStation use the shipping option the customer chose at checkout?
Yes. The checkout selection arrives as the Requested Service, and it is available to automation rules as criteria — both the raw marketplace value and the value after Service Mapping has run. So each option on your storefront can route to its own Rate Shopper configuration.
That matters because the checkout selection is the only record of what you promised. A single rate shopper across all orders will happily win a cheap slow service on an order somebody paid a premium to have quickly. One configuration per shipping option you sell, routed on the requested service, keeps the price comparison while making sure every possible winner honours the promise.
9. Rate Shopper
What to set. One strategy per shipping option you sell. A ground strategy holding the services that can carry a ground promise, a two-day strategy holding the ones that can carry that, and so on. Put every service that could legitimately win into its strategy.
Why it belongs here. Rate Shopper is not a layer in the documented sequence — it is applied by the Set Rate Shopper rule action, so it executes inside the rules. But the strategy has to exist before a rule can name it, which puts building it here in setup order.
What breaks without it. A strategy with too few eligible services returns the cheapest of a short list and looks like it worked. And the rule that sets package dimensions must sit above the rule that applies the strategy, because a rate is only as good as the package it was quoted for — ShipStation documents that dependency directly.
Can ShipStation rate shop across carriers automatically?
Yes. Rate Shopper pulls live rates from your connected carriers and applies the winner, using a Cheapest, Fastest, or Best Value strategy — or a custom configuration, where the account's plan includes it. ShipStation documents three ways to apply it: from an automation rule using the Set Rate Shopper action, from the Service drop-down on a single order, or in bulk across a selection of orders.
It's more thoughtful than people expect. Service Preferences let a preferred carrier win when it's within a cost threshold of the cheapest. Delivery time constraints restrict eligible services by carrier transit estimate, counted in business days from the day after ship date. Available for US, UK, Canada, Australia, and New Zealand accounts; plan-gated.
How ShipStation Rate Shopper Works, and How to Configure It Well →
10. Automation rules
What to set. Two passes. Rules that classify an order and tag it, then rules that read those tags and act. Within each pass, order matters: rules run top to bottom and later ones override earlier ones. Keep the dependencies straight — service before carrier-specific insurance, dimensions before Rate Shopper, a tag before any rule keyed to that tag.
Why it belongs here. Rules run last, which is what makes them able to override every layer above. That is a reason to put less in them, not more. This is the first layer that sees the order as a whole rather than a product, so anything that depends on the basket has to be here — and anything that does not, should not.
What breaks without it. A rule with a blank criteria or action fails, and fails every rule below it in the list, with no warning. SKU, Item Name and Warehouse Location criteria skip multi-item orders entirely, which are usually the complicated ones. And an override leaves no trace beyond the order activity log, so two rules setting the same field look identical to one rule working.
What order does ShipStation automation run in?
Auto-Routing and Auto-Split, then SmartFill, then Preset Groups, then Product Defaults, then Service Mapping, then Automation Rules last. Within rules, ShipStation processes your list top to bottom, and later rules override earlier ones.
SmartFill is the one most people do not know is in the chain: it is on by default and fills weight and dimensions from your own recent labels, and everything below it overwrites it. The sequence is also why rules have dependencies you manage yourself — service before insurance, dimensions before Rate Shopper, a tag before any rule keyed to that tag.
How ShipStation Automation Rules Work: A Complete Reference →
Operating it
The layers above decide what happens to an order that fits a pattern you anticipated. These two are for the orders that do not, and they are the part most accounts never build. An alert is a decision routed to a person rather than made by a rule, which is a legitimate outcome and not a failure of the configuration.
11. Alerts
What to set. For each condition a person needs to handle, a rule with two actions: a tag to filter on, and an alert or an email so somebody is told. Start with address validation, which nearly every account should have — ShipStation validates every order and does not stop a label on a warning or an error.
Why it belongs here. Alerts are rule actions, so they belong at the same layer as the rules and are built in the same pass. They are the honest answer for anything the engine can identify but cannot decide, and building one is how that decision reaches the right desk on the day the order lands rather than at the bench three days later.
What breaks without it. Without them, the orders your rules could not handle are indistinguishable on the grid from the ones they handled correctly. They ship anyway. Note also that dismissing an alert dismisses it for that user only, so an alert somebody cleared is still waiting for everyone else.
How do I create an alert in ShipStation?
With an automation rule. Two actions produce a notice: Create an Alert, which puts a message in the numbered alert list next to the profile icon with text and an expiry you set, and Send an email, which emails a named address when the rule runs. A third, Add a Tag, produces something to filter on rather than something to read. Most alerts are worth building as a tag plus one of the other two, because they reach different people at different moments.
Alert text takes four field replacements — Store Name, Recipient Name, Order Date and Order # — and an Order # replacement renders as a link to the order. Dismissing an alert dismisses it for that user only, so the same alert is still waiting for everyone else.
12. Saved views
What to set. One view per exception queue you route, filtered on the tags your rules apply, with the columns relevant to that exception. Plus one view of everything sorted by Age, descending, with no filters at all. Then decide who opens which, and when.
Why it belongs here. A view is where the tags from the layer above get read. It is last because it is the only part of the configuration that depends on every other part being done — you cannot filter on a classification nothing applies.
What breaks without it. Nothing, mechanically, which is why it gets skipped. What breaks is operational: an exception queue nobody opens is the same as no exception queue. A saved view shows orders and does not act on them, so the configuration above has to be right regardless.
How do I make a folder of certain orders in ShipStation?
ShipStation does not use the word folder. What you want is a saved view: filter the Orders grid, then click Custom View - Click to Save and name it. It becomes a tab across the top of the grid carrying a live count of how many orders match, and it saves your column selection and column order along with the filters. The new layout allows an unlimited number; ShipStation Legacy caps them at five.
Saved views are available to every user on the account, so this is a shared piece of workflow rather than a personal one. What each user sees inside a view can still differ, because a per-user restriction can limit someone to only the orders assigned to them.
How to Make a Folder of Orders That Need Checking in ShipStation →
When the twelve are done
Most accounts that feel like they need something extra have four or five of these missing, and the missing ones are usually 3 and 4 — the product data and the tags — because both are data entry rather than configuration. Working through them in order tends to resolve more than expected, and it is worth doing before concluding anything about the platform.
What genuinely does not fit inside these layers is a smaller set than it looks: decisions that need the actual contents of a mixed order, that need arithmetic, or that need data the order does not carry. The automation guide covers where each of those lines falls, capability by capability. If you have configured all twelve and something still does not work, that is the page to read next, and it is the honest place to find out whether the problem is configuration at all.
Working through all twelve is a week of work, and not everybody wants to spend it. If you would rather, I will go through your account against this list and tell you what is missing and in what order to fix it — that is the configuration review, and it costs nothing.