Published
Yes, ShipStation automates this, and it is one of the better-supported actions in the rules engine. Insure the Package is a standard automation action — ShipStation’s criteria and actions reference describes it as automatically assigning a specific insurance provider to the matched order — and there is a prebuilt template for it if you would rather not start from scratch.
The rule takes a couple of minutes. The part worth reading afterwards is what it sets the amount to, because that is the one decision it makes for you.
The criteria are the full set. Insurance is not a special case with its own restricted criteria list; it is an ordinary action, so anything the engine can read can trigger it. That includes Order Total, Order Subtotal, Amount Paid, Order Weight, Order Tags, Country, State, USPS Zone, Ship From Location, Marketplace and Store, among about forty others in the reference. ShipStation’s worked example combines three of them: coverage applies where the order ships from a particular location, goes to one of three named cities, and has an order total over $100.
That range is the useful part. “Insure everything over $200” is the obvious rule and rarely the right one — “insure everything over $200, plus anything tagged fragile, plus everything going to these three postcodes regardless of value” is expressible in the same engine and closer to how loss actually distributes.
There is a template. ShipStation’s Automation Overview page, under the Automations tab, carries prebuilt rule templates for common workflows, and insurance is one of the examples ShipStation names. Fields needing your input are outlined in blue, and every template is editable after you enable it. The same page lists which automations are already active in your account, which is worth a look on its own if you have inherited someone else’s configuration.
Four ways to apply it, not one. The rule is the automated path, and the others matter because they are what you fall back on:
Providers, by account country. As of August 2026, ShipStation documents ParcelGuard for US accounts on the current interface, Shipsurance for US accounts still on ShipStation Legacy, and Total Shipping Protection by XCover for Canada, the UK, Australia and New Zealand. Alongside those sit carrier insurance, bought from the carrier moving the parcel, and an External option that records cover you bought elsewhere. Carrier and External can each be switched off account-wide under Settings → Shipping → Insurance, which is worth doing if you have standardised on one provider and do not want a packer choosing differently at the shipment screen.
Claims come back into the same grid. For ParcelGuard, Shipsurance and Total Shipping Protection, you file from the shipment record in the Shipments grid by clicking the provider link in the Insurance column. If you cannot see it, the Insurance column is hidden — enable it from the Columns button. Carrier insurance claims go through the carrier’s own portal instead, and ShipStation links out to the common ones.
One thing to get right in the criteria: numeric fields take numbers only. ShipStation documents that currency symbols cannot be used in the fields for numerical values, so 100 and not $100. A rule with a rejected value in it is one of the ways rules fail quietly, which is covered in how the rules engine actually behaves.
From the same article:
When an automation rule adds insurance to an order, the insured amount will always default to the order’s Amount Paid. You cannot set a different amount in the rule, but you can manually adjust the amount on the order before you create the label, if needed.
So the rule chooses whether to insure. Amount Paid chooses for how much.
That is a defensible default. Amount Paid is the one figure a shipping platform can be confident about, because the channel sent it; replacement cost is a number only you hold, and it lives in a system ShipStation has no view of. Picking the known field over a guess is the right call for a platform serving every kind of merchant.
It is still worth knowing which direction it is wrong in for you, because that depends on how you sell. Amount Paid is what the customer handed over. It carries discounts, promotional pricing and gift card redemptions downward, and it carries tax and shipping upward. A $400 item sold at half price on a promotion insures for $200 and costs you $400 to replace. A $60 order with $18 of expedited shipping on it insures for $78, and you pay premium on freight you would not be replacing.
Neither is catastrophic on one parcel. Across a season of promotional volume the first one is a real gap, and it is invisible, because nothing in the interface tells you the declared value stopped matching replacement cost.
The practical shape of this: automate the decision, and treat the amount as correct for full-price orders and as something to check on discounted ones. If a large share of your volume is promotional, the rule is doing less for you than it looks like it is.
ShipStation’s troubleshooting guide lists insurance as its example of a rule with a prerequisite:
For rules that update carrier-specific shipping options like insurance the Shipping Service must be set prior to Insurance being added. If this was not the case, the Insurance rule may fail.
Rules run top to bottom in list order. If your insurance rule sits above the rule that sets the carrier and service, it can fail, and a failed rule does not announce itself. Put the insurance rule below service selection and confirm on a real order that the Insurance column is populated before you trust the rule across your volume.
This is the same class of dependency as tag chaining, and it has the same fix: order of operations is something you control, and it is worth reading your rule list as a sequence rather than a set.
Multi-package shipments. If a shipment has more than one package, ShipStation disables the Insured Amount field on the shipment and requires the amount to be entered per package inside the Multi-Package Shipment editor. There is no rule action that reaches into a multi-package configuration. If you ship a meaningful volume of multi-box orders, insurance on those is a manual step and will stay one.
Carrier insurance. The rule action adds ShipStation’s insurance partner. Carrier insurance — coverage bought from UPS, FedEx or whoever is carrying the parcel — is a separate option on the shipment. It exists to top up coverage above whatever the carrier already includes by default, and ShipStation notes that not all carriers provide default coverage or the option to buy more.
Worth knowing when you set the amount by hand: ShipStation’s instruction is to enter the full declared value and not to subtract the carrier’s default coverage.
External insurance. If you have your own policy with a provider ShipStation does not integrate, the External option marks the shipment as covered. It is a record only. It does not let you file a claim through ShipStation or store the insurer’s name.
Total Shipping Protection is priced as a percentage of the amount you declare. As of August 2026, ShipStation documents 1.25% of the insured amount for domestic shipments and 1.75% for international. Check the current figure before you build a threshold around it. So the difference between insuring at $200 and insuring at $400 on a domestic parcel is $2.50, which is the argument for accepting Amount Paid on ordinary orders and the argument against ignoring it on high-value ones.
ShipStation does not publish a rate for ParcelGuard, and I am not going to estimate one. Fees for both come out of your ShipStation Balance rather than your subscription payment method, which matters mainly because it is a different line to reconcile — the balance’s Transaction History lists insurance purchases separately from label purchases.
The threshold is not a shipping question. It is the point where the premium stops being cheaper than self-insuring, and that depends on your loss rate and your average order value, both of which you have.
Insure everything and you pay a percentage on every parcel including the ones that were never at risk. Insure nothing and you absorb the tail. Most operations end up with a value threshold plus a small number of categories that are always insured regardless — fragile, high-theft, or hard to replace — and that shape maps cleanly onto rule criteria: one rule on order value, one rule on a product tag.
Product tags are applied before automation runs, so a tag-based insurance rule is safe anywhere in the list on that count. It still needs to sit below service selection.
Once the rule has been running a month, pull a shipment export and check three things: that insured shipments are the ones you meant to insure, that the declared amounts look like replacement cost rather than post-discount cost, and that no multi-package shipments are sitting uninsured because the rule could not reach them. All three are visible in the export, and none of them are visible in the interface.
Insurance is a way of paying to convert an unpredictable loss into a predictable cost. It does not reduce the loss rate. If a particular lane, carrier or product is generating claims, the coverage is treating the symptom, and the underlying question is a packaging or carrier question rather than an insurance one.
It also does not cover the thing most operations actually lose money on, which is not lost parcels but charges added after the label was bought. Those are not an insurable event. They are a measurement problem.
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.
