Updated
Short answer: for US domestic parcels, yes. It runs on every order without anyone configuring it, and it is as good as the postal database behind it, which is the same database the carrier uses to decide whether your parcel is deliverable.
Internationally the answer is not one answer, and it depends first on which surface you are using. In the application, address verification covers eleven countries. Through the ShipStation API it covers those eleven and, in ShipStation’s own words, over 160 others — but not to the same depth in each, and the depth is published country by country. On some lanes a verified address means the building was found. On others it means the city was found. Treating those two as the same status is where the trouble starts.
Address validation is asked to do three different jobs, and it does them to different standards.
The first is deliverability: is this a real address that a carrier will accept and a driver can find. The second is rate accuracy: is this address residential or commercial, which changes what the label costs. The third is data hygiene: standardising what a customer typed into what the postal service recognises.
They are worth separating because ShipStation is strong at the first and third, and the second is a different problem with a different answer. What the residential flag actually tells you covers the second in full, and this page does not repeat it.
ShipStation’s API documentation defines four validation statuses, and the exact wording is worth reading closely because two of them get conflated:
The distinction that matters operationally is between unverified and error. An error means the address reached the database and nothing matched it with confidence. Unverified means it never reached the database at all, because it failed a check before that point. Those have different causes and different fixes. An error is usually a wrong address. Unverified is usually a malformed one, or a country the request could not route.
If you are building any kind of exception queue, that is the split to build it on. Errors go to someone who contacts the customer. Unverified goes to whoever owns the data coming out of the selling channel.
This is the plain answer and it is worth stating without qualification. ShipStation runs address validation on every order shipping to and within the supported countries, and auto-corrects domestic and international addresses for those countries. It costs nothing, there is nothing to configure, and for a domestic parcel it resolves against the postal database that decides deliverability in the first place — ShipStation names it as the USPS address validation database for US orders, and the Melissa database for the other supported countries.
It also improves the address rather than just grading it. ShipStation’s documentation notes that when validation finds a more precise match, the shipment comes back carrying the updated values — their example is a postal code enriched to ZIP+4. That is a small thing that quietly reduces the rate of parcels that go to a sortation exception.
For a US domestic operation, there is no configuration decision to make here and no third-party tool that is worth adding. The honest answer is that the platform does this correctly.
This is the part worth knowing before you assume a status means what you think it means, and it starts with a distinction the two sets of documentation do not draw for you.
In the application, the supported list is short. ShipStation’s Address Validation article names the countries its Address Verification feature supports, and as of September 2026 there are eleven: Australia, Canada, France, Germany, Great Britain, Israel, Italy, Norway, Spain, Sweden and the United States. Ship outside that list and validation does not return a shallow answer — it returns no answer. ShipStation documents the not-verified state as covering two cases, and one of them is that “ShipStation ran the address verification, but the ship-to country is not supported, so address verification could not be completed.”
That is worth sitting with if you ship broadly. An unverified icon on an order to a country not on the list is not a data quality signal about that address. It is the absence of a check.
Through the API, the surface is much wider and the depth varies. ShipStation’s API documentation describes validation for the same eleven countries “and over 160 others”, and publishes address validation support by country stating directly that “the level of validation that ShipStation API can provide varies from country to country.”
Five levels are defined, from most to least precise — Suite/Unit Number, House/Building, Neighborhood/Urbanization, City/Municipality and State/Province — though as of September 2026 only the first four have countries assigned to them. The distribution, also as of September 2026:
| Level | Countries and territories | Examples |
|---|---|---|
| Suite/Unit Number | 21 | Australia, Canada, France, Germany, Japan, South Korea, the Netherlands, the UK, the US |
| House/Building | 89 | Spain, Italy, Norway, Sweden, Mexico, India, Poland, South Africa |
| Neighborhood/Urbanization | 50 | Albania, Angola, China, Costa Rica, Kenya, Nigeria |
| City/Municipality | 74 | Iraq, Pakistan, Ethiopia, Mongolia, Yemen |
Two things fall out of that table. Only 21 countries validate to the apartment. And six of the eleven the application supports — Spain, Italy, Norway, Sweden, Israel and Great Britain among the named set — do not sit in the top tier on the API’s own list.
Here is what a shallow level means on a live order.
A customer in a City/Municipality country orders through an integration. The address they typed has a street, a building number and an apartment. Validation checks it and returns verified. What has been confirmed is that the city and the postal code exist and correspond. The street was not checked. The building number was not checked. The apartment was not checked, because there is no database available to check them against.
The status is accurate. It is answering a narrower question than the same status answers on a US order, and nothing in the response distinguishes the two. So a verified international address at a shallow level carries roughly the confidence of a spell-check, and if your exception process trusts the status uniformly, those are the parcels that go missing.
The application has its own, coarser version of the same idea, and it is documented plainly. An Address Verification Warning means “the core components of the address (Address 1, City, State, and Postal Code) verified successfully, but there is either missing or extra information in the address that is preventing full validation” — ShipStation’s own example is an apartment number in address line 2 that cannot be verified. Which is the depth question wearing a different name: the address verified to the building and not to the unit.
The practical consequence is the same on both surfaces. Validation status is a good filter for your domestic volume and a weaker one for parts of your international volume. Check the level for the countries you actually ship to before you decide how much weight the flag carries. For most operations that is a short list.
One scoping note, because the two sets of documentation answer different questions. The level table above is published for the ShipStation API. ShipStation does not separately document the validation depth the application achieves country by country, and the two surfaces demonstrably differ in coverage — eleven countries against a hundred and seventy-odd. The eleven are common ground, named in both. Beyond them, treat the table as describing what the API does, and treat the application’s behaviour outside its supported list as documented only to the extent quoted above: verification does not complete.
This is the one that catches people moving volume from the interface to an integration.
Start with how ShipStation separates the two words. Warnings “don’t stop you from creating shipping labels” and “exist to bring something to your attention that might influence your shipping decision”. An error “blocks you from creating a shipping label and requires you to make some kind of change”. So the app does have a gate, and it is the error class that closes it.
Address verification is the interesting case because it sits on the permissive side, and ShipStation says so for both classes. A verification warning and a verification error each “will not prevent you from attempting to create a label” — but if the postage provider then finds fault with the address, it may reject the attempt and return an error of its own, which you would have to correct before the label goes out. You find out at the provider rather than before.
Via the API it is a choice you make per request. ShipStation documents three values for validate_address: no_validation, which is the default, validate_only, and validate_and_clean. Set either of the latter two and the consequence is explicit — if an address cannot be validated, an error is returned and the label is not created.
So the same address can be a printed label in the app and a hard failure through the API, depending on a property the integration sets. The default is no_validation, which means an integration that never sets it gets no validation at all — not the app’s advisory behaviour, but nothing. If you are automating label creation against orders a person used to eyeball, that is the setting to look at first.
Worth also knowing that the detail in the error message varies by country, for the same reason the validation level does. A rejection on a shallow lane will tell you less about what was wrong.
One thing, and it is worth stating as a fact rather than a complaint.
Validation confirms an address against a postal database. It does not confirm how a carrier will classify that address for billing, and ShipStation says as much: the residential marker comes from its own data source and may not match what UPS or FedEx decide. Two organisations maintain two datasets about what sits at an address and they diverge at the edges. That is a property of the problem, not of the platform, and the residential flag post covers what to do about it.
The second thing validation does not do is act. It grades every address and then leaves the grade sitting on the order. Turning a grade into a decision — hold this one, tag that one, alert somebody — is a rules job, and ShipStation automation rules expose the verification status as a criterion you can key on.
Three things, in order of what they are likely to return.
Take your top five international destinations and check them twice. First against the eleven countries the application supports — if a destination is not on that list, orders to it are not being verified at all, and the icon is telling you nothing about the address. Then, if you create labels through the API, against the published level for that country: a destination at City/Municipality returns verified on evidence that the city exists. Both checks take ten minutes and they change what your exception process should do with those orders.
Split your exception handling between error and unverified. They are different failures with different owners, and the statuses already separate them for you.
If you have an integration creating labels, check which validate_address value it sets. The default is no validation. That may be what you want, or it may be that nobody chose it.
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.
