If you have searched for shipstation hazmat support (or the Shippo or EasyPost equivalent), you have probably found documentation that answers a slightly different question to the one you asked. That is not evasion on their part. It reflects a real division of labour that is worth understanding before you build around it.
This review covers what each platform genuinely does for dangerous goods, what none of them do, and where the responsibility actually sits. The short version: shipstation hazmat features, and the equivalents elsewhere, are a transport layer for data you have to produce somewhere else.
What these platforms are for
ShipStation, Shippo and EasyPost are multi-carrier shipping layers. They aggregate carrier accounts, fetch rates, buy postage, generate labels and normalise tracking. They are very good at that, and it is a genuinely hard problem.
Classification is a different problem entirely. It asks: given this product, what is it under 49 CFR? That requires an encoded regulatory ruleset, versioned against editions, with the criteria for each hazard class. It is not something a rating engine is built to do, and none of these platforms claims to do it.
What ShipStation hazmat support and its rivals offer
| Capability | ShipStation | Shippo | EasyPost |
|---|---|---|---|
| Determines your product's UN number | No | No | No |
| Passes hazmat fields to carriers that expose them | Yes, integration dependent | Yes, integration dependent | Yes, integration dependent |
| Prints carrier-compliant hazmat labels | Where carrier supports it | Where carrier supports it | Where carrier supports it |
| Filters services by hazmat acceptance before rating | Not by default | Not by default | Not by default |
| Validates that a classification is correct | No | No | No |
| Tracks regulatory edition changes | No | No | No |
| Stores a determination against a SKU | Custom fields only | Metadata only | Metadata only |
Read down the first column. Every "No" is a thing the platform never promised, and every one of them is a thing somebody has to do.
It is worth saying plainly, because the search results for shipstation hazmat and its competitors tend to blur it: none of these vendors is hiding a classification engine behind a feature flag. The capability does not exist in this category of product, and expecting it is the mistake.
Where the gap bites
The failure is not that platforms lack a feature. It is that the missing step is invisible, because everything downstream of it works perfectly.
Picture the flow in a typical stack. An order arrives. The platform fetches rates across four carriers. A rule picks the cheapest service inside the delivery window. A label is generated and paid for. The parcel is picked, packed and manifested. Every step succeeds.
At no point did anything ask whether the item was a dangerous good. If it was an aerosol, the selected service may not accept it, and nothing in that chain would have said so. The failure surfaces physically, at a sort facility, days later — and often the rejection reason that comes back is generic enough that the same parcel gets relabelled and sent again.
A shipping platform will print a label with whatever UN number you hand it, including one that is wrong. The label being valid and the declaration being true are two different properties, and only one of them gets checked at label creation.
Classify7 ruleset team
Putting the steps in the right order
The fix is architectural rather than a matter of picking a better platform. Classification belongs upstream of rating, not alongside label generation.
- At listing or product creation — classify the SKU. Store UN number, proper shipping name, class, packing group and the ruleset version against the product record.
- At order creation — read the stored determination. If the order contains regulated items, mark it.
- At rating — filter the candidate services by hazmat acceptance for those UN numbers, then rate-shop within what remains.
- At label generation — pass the stored classification into the platform's dangerous goods fields.
- On edition change — re-run stored determinations and flag anything that moved.
Steps 1, 3 and 5 are the ones no shipping platform performs. They are also the ones that carry the legal exposure, because under 49 CFR 172.101 the duty to classify correctly sits with the shipper — not with the platform, not with the carrier, and not with a 3PL.
What to store, and where
If you are wiring classification into a platform, the question that comes up immediately is where the determination should live. Product record, order record, or both.
The answer is both, for different reasons.
On the product record goes the determination itself: UN number, proper shipping name, class, packing group, packing instruction where relevant, and the ruleset version it was made against. This is the durable fact about the SKU, and the ruleset version is what makes a future re-check scopeable.
On the order record goes the snapshot used for that specific shipment, plus the carrier and service chosen. This matters because a determination can change between when an order is placed and when a question is asked about it six months later, and you want to know what was true at despatch.
In practice ShipStation hazmat data tends to live in custom fields on the product, with Shippo and EasyPost using metadata for the same purpose. None of the three is designed as a system of record for compliance data, so treat their storage as a cache of something authoritative held elsewhere rather than as the master copy.
The one thing not to do is store a bare UN number with nothing beside it. A UN number without its packing instruction and packing group is exactly the record that develops internal contradictions, and the contradiction is what a carrier's screening catches. A ShipStation hazmat custom field holding four digits and nothing else is a liability dressed up as a record.
Verdict on each
ShipStation — strong on the merchant-facing workflow, and ShipStation hazmat handling is as good as a label layer can reasonably be, with custom fields you can press into service for storing a classification against a product. Good choice if your team lives in an operations interface rather than in code. It will not tell you what to put in those fields.
Shippo — clean API, straightforward multi-carrier rating, popular with smaller merchants. Same boundary. Metadata is where a determination would live if you put one there.
EasyPost — the most developer-oriented of the three and the easiest to compose with another service, which matters here, because composing is precisely what you need to do. If you are going to insert a classification call before rating, this is the least awkward place to do it.
None of them is deficient. They are all doing their job. The mistake is assuming their job includes the determination.
- Assuming a printed label means an accepted shipment.
- Rate-shopping before filtering services for hazmat acceptance.
- Storing a UN number in a free-text field with no packing instruction beside it, so the two can silently disagree.
- Expecting the platform to notice a regulatory edition change.
- Treating a carrier's acceptance of one shipment as approval of the SKU.
Filling the gap left by shipstation hazmat fields
A classification call is a small addition to an existing stack. POST /api/classify takes the product description or composition and returns the UN number, proper shipping name, class, packing group and a carrier eligibility block covering UPS, FedEx, USPS and Amazon — which is exactly the data the filtering step in point 3 needs.
For catalogue-wide work, POST /api/classify/batch handles up to 500 SKUs per call, so you can find out which of your existing products would have failed a filter you did not have. Subscribe the regulated ones as monitored SKUs and the re-run in step 5 happens without anyone remembering to do it.
For the wider tooling landscape, see our comparison of dangerous goods classification software. For why the acceptance filter matters so much, see dangerous cargo classification across UPS, FedEx and USPS. And if you are not yet sure which of your SKUs are regulated at all, start with dangerous goods classification and whether your product is hazmat.
Whichever platform you settle on, the obligation underneath is the same and it does not move: 49 CFR 172.101 puts classification on the shipper, and PHMSA enforces it against the shipper — not against the software that printed the label.
