Published
You can hold more than one account with the same carrier in ShipStation, and the first one you connect becomes the primary. ShipStation states that it always defaults to the primary account for a carrier when you select a carrier service for a shipment, so running two accounts is really one question: how does an order get to the other one.
There are three answers — change the Shipping Account on the order, apply it to a selection in bulk, or set it at import with an automation rule — and the third is the only one that scales. The rest of this is about where that rule goes, because placing it wrong is the failure mode, and it produces orders with no shipping service on them at the packing bench.
This post assumes you already have two accounts and is about routing between them. Whether to connect a second one at all is the other half of the question and has a different answer — the capability differences, the fee regimes, and why a contract that loses on most of your volume is still worth connecting covers that for FedEx, and the UPS version resolves differently.
Three reasons come up, and they want different things from the configuration.
A negotiated contract alongside the platform’s rates. You have your own FedEx or UPS account and ShipStation’s included rates are also on the file. Neither wins everywhere. In the accounts I work in, the account that takes a heavy commercial delivery is rarely the one that takes a two-pound residential parcel, and choosing a side means being wrong on part of the volume by design. Here you want a rate comparison to decide per order rather than a rule.
Two entities, or a client’s account. A second legal entity, a second region, a brand billed separately, or a 3PL creating labels on a customer’s account. The routing is deterministic — this store’s orders go to that account — and a rule expresses it exactly.
A service that only exists on one of them. Ground Economy approval, a contract service, a regional add-on. The account follows the service rather than the other way round, which is the case where rule placement matters most.
Not all carriers allow multiple accounts in ShipStation, and ShipStation’s Carrier Integration Guide is where that is listed per carrier. It is the first thing to check. ShipStation also recommends giving each account a unique nickname, and that sounds like housekeeping and is not: the nickname is what you are picking between in the service menu, and two accounts both labelled FedEx is how the wrong one gets chosen.
ShipStation documents the rule plainly: when you connect multiple accounts for a single carrier, the first account you connect is the primary, and it is the account automatically selected when you set a service from that carrier. To move it, open the carrier’s settings and check Make this my primary account.
That is worth deciding deliberately rather than inheriting from connection order. Everything below is about the exceptions, and the exceptions all fall back to the primary — so the primary should be the account you want when nothing else has an opinion, which for most operations is the one carrying the majority of volume.
Two is the common case, not the limit. ShipStation’s instruction for adding more accounts on a carrier is to repeat the provider connection process, and it publishes no cap on how many. The structure is one primary and any number of others, and nothing below changes at three or five — you are still setting the account with the same rule action, in the same place in the list, against the same exceptions. What scales is the number of rules: one routing decision, one rule, each placed by the same reasoning. Two entities alongside the platform’s own rates is three accounts, one of them primary, and two rules.
Three documented mechanisms, in ascending order of how much work they save.
On the order. Change the account using the Shipping Account drop-down in the Other Shipping Options section, either in the Shipping Sidebar in the Orders grid or on the Order Details screen.
In bulk. Select the orders and apply the account to the selection.
At import, by rule. The action is Charge Shipping to My Account, and ShipStation’s criteria and actions reference describes it as designating your pre-selected shipping account as the payor of the shipping charges. Its own note is direct about when to use it: only if you have multiple accounts connected for a single carrier. With one account per carrier the action does nothing you need.
There is a fourth thing that looks like a mechanism and is not. Presets are covered below.
This is the part worth reading twice, and it is documented rather than folklore.
From the same criteria and actions reference, on Charge Shipping to My Account:
If a shipping service is already selected for the order but does not match the services provided by the carrier account set by this action, ShipStation will clear the order’s shipping service.
Read what that means operationally. The rule does not warn, does not skip, and does not pick a substitute service. It removes the service from the order and leaves everything else intact. The order continues down the rest of the rule list, imports successfully, and appears in Awaiting Shipment looking normal apart from an empty service field.
That is the same shape as most automation failures in ShipStation — nothing errors, the order just arrives configured differently than you expected — and it is why the placement question below has a real cost attached rather than being a tidiness preference.
ShipStation processes automation rules from first to last in the list. Combined with the clearing behaviour, that makes placement the entire decision, and the correct placement is opposite in the two common setups.
The service is already on the order by the time the account rule fires, so the account you select has to be one that offers that service. Both halves of this are documented: rules run in list order, and the account action clears a service the selected account does not offer.
Put the account rule above instead, and the sequence runs: account rule selects an account for an order that has no service yet, nothing to clear, no complaint; then the service rule sets a service that may belong to the other account. Nothing clears at that point either, because the clearing check belongs to the account action and it has already run. You get an order carrying an account and a service that do not go together, and you find out when the label fails or when the invoice arrives against the wrong account.
Rate Shopper is applied by its own rule action, Set Rate Shopper, which means it is a step in the same list rather than something that happens outside it. Put the account rule above it and the account is already on the order when Rate Shopper runs, with no service present for a mismatch to clear.
This second case is an operating observation rather than a citation, and I want to be exact about which parts are which. What ShipStation documents is the general principle, in the Rate Shopper article, for the dimensions-then-rate-shop case: “The sequence of these rules is crucial as Automation Rules run according to their sequence in the rules list.” Its example is a Set Package Dimensions rule that must precede the Rate Shopper rule so that every order can generate a rate. The account-then-Rate-Shopper pairing is the same principle applied to a different prerequisite, and it is not written down anywhere I can point you to. Test it on a handful of orders before you trust it with a morning’s volume.
One documented Rate Shopper property is worth holding alongside this. Rate Shopper compares services, not package types, and the services you put in a strategy are the whole of the comparison. Which accounts are represented in a strategy is therefore a function of which services you selected when you built it, and that is where a two-account setup either works or quietly does not.
Rules are the last stage. Auto-Routing, Auto-Split, Preset Groups, Product Defaults and Service Mapping all run before any rule does, and ShipStation states that automation rules can override Product Defaults and Service Mapping, as well as rules applied earlier in the sequence.
So a service arriving from a Product Default or from Service Mapping is already on the order before your first rule is evaluated. The static case above therefore applies to it — the service is set — but there is nothing to sequence against, because that stage finished before the rule list started. Ordering only ever means ordering against your own rules.
Three exceptions, and none of them can be configured around.
Return labels. ShipStation states that return labels always use the primary account. If your returns should bill to the second account, they will not.
Labels created in the Rate Calculator. Same sentence, same article. A label created directly in the Rate Calculator uses the primary account regardless of what the order says.
Anything that bypasses import. This one is a consequence rather than a documented item, and it follows from the mechanism. The account decision is expressed as a rule evaluated when the order imports or first moves into Awaiting Shipment. A label created outside that path never has the rule applied to it, so it lands on the primary account by default.
That is a real operating constraint rather than a defect, and it has a clean design implication: the primary account should be the one you want as the fallback, not merely the one you happened to connect first.
ShipStation’s carrier accounts article states that Shipping Presets do not provide the option to change the carrier account within the preset, and that you change the account manually on the order before creating the label.
The Use Shipping Presets article says something narrower and more specific:
If you have multiple accounts with a carrier, we recommend sorting by account so you can specify which account to use with the preset. If you sort by carrier, the service you choose will always use the account designated as the primary carrier account.
Those two are not saying quite the same thing, and the practical position that follows from both is the conservative one. A preset is not the mechanism for routing an order to a non-primary account — the rule action is. But if you already have presets in use on a two-account setup, the sort setting on the Shipping Options service list is worth checking today, because a preset built from a carrier-sorted list silently uses the primary account and there is nothing on the preset to tell you so.
Presets and Preset Groups are two different features with opposite purposes, and neither one carries an account decision.
Worth pricing before you build the routing, because on one plan type it changes which account should win.
ShipStation’s shipment fee schedule states that connecting your own carrier accounts requires the Your Carriers add-on, and that the add-on fee applies to Legacy plans only — priced by tier, $5/month on Starter up to $95/month on Scale – Enterprise. If you signed up on or after 9 July 2025, or moved from a Legacy plan to Standard or Premium, there is no additional fee. On High Volume plans the add-on is included and every shipment created against your own carrier account incurs a per-shipment fee instead, where a shipment means any label, fulfillment, or order marked as shipped.
The High Volume case is the one that interacts with routing. A rate comparison prices carrier rates and nothing in it accounts for a per-shipment fee on one side, so on that plan a rate that wins by a few cents may not be the cheaper order. That is not a Rate Shopper defect — it is comparing what it says it compares — but it means the account rule and the rate comparison are answering slightly different questions.
ShipStation handles two accounts well. They coexist, rates compare across them, an automation rule routes between them at import, and the boundaries are documented rather than discovered.
The boundary is that the account decision is static. It is a rule evaluated on import against fields already on the order, so it can express this store’s orders go to that account or these states go to that account precisely. What it cannot express is anything that depends on the outcome of a later step — the account that turned out cheaper for this particular parcel, the account whose service survived a dimension change, the account that should take the order because the other one’s contract minimum is already met this month. Those need the answer before the question, and a static rule evaluated at import does not have it.
That is the same shape as most of what the rules engine cannot do, and it is not a deficiency so much as the nature of a static IF/THEN engine evaluated once, at import, against a fixed set of fields.
Which account is primary, and is it the one you want as the fallback? Return labels and Rate Calculator labels go there no matter what, so the primary should be a deliberate choice rather than an artefact of connection order.
Are your accounts nicknamed distinctly? Two entries reading FedEx in a service menu is a configuration error waiting for a busy afternoon.
Where is the account rule relative to whatever sets your service? After a static rule or service mapping. Before a Rate Shopper rule. If you have both patterns in the same account, you need two account rules with different criteria, not one placed in the middle.
Is the Shipping Options list sorted by account or by carrier? If by carrier, every preset in the account is using the primary regardless of the service it names.
On High Volume, does the per-shipment fee change which account should win? It is a fixed amount per label against a rate difference that varies per order, so it flips the answer on the parcels where the two accounts are close and nowhere else.
String builds and maintains logic like this inside existing ShipStation accounts — cartonization, rate selection, batching, inventory-aware holds, cold chain rules. No dashboard, nothing for your team to learn.
Typically for operations past 6,000 orders a month with a dedicated fulfillment team.
