Address Validation and the Unit Designator Problem

An address can validate perfectly and still be undeliverable in the way that matters: the street address is real, the postcode is right, and the flat, suite, or unit number, the part that decides whose door the parcel reaches, was dropped, mangled, or never captured. Unit designators are the least standardised part of an address and the part validation systems handle worst.

Designators are a zoo

Apt, Ste, Unit, #, Fl, Bsmt, Dept, and the building specific inventions customers type from memory do not map cleanly onto the secondary unit designators postal databases recognise. A customer writing Suite 400, a database holding STE 400, and a checkout normalising #400 are describing the same door, but a validation routine doing literal matching can flag the address as unconfirmed or, worse, strip the unfamiliar part and call the remainder valid.

Multi building complexes add a second failure: the building number is part of the primary address in the postal record, while customers treat it as part of the unit. Validation that cannot reconcile the two orders returns a correction that is itself wrong.

The dropped unit failure mode

The expensive failure is silent acceptance. The address validates at street level, the unit line is discarded somewhere between checkout, warehouse system, and carrier label, and the parcel arrives at a 200 unit building addressed to nobody in particular. Delivery outcome: left in a lobby, returned to sender, or signed for by the wrong floor, each generating a support contact that says the address was entered correctly, because it was.

Any validation integration should be tested on this exact case. Feed it known addresses with units in varied formats and check what reaches the label, not what the validation response claimed. The response and the label are different systems with different opinions.

Capture design beats correction

A dedicated secondary address line, labelled in the customer's language with examples, Apartment, suite, unit, outperforms a single free text address box at getting units captured in a parseable place. Autocomplete helps street accuracy and hurts here when it fills the primary address and the customer never adds the unit the suggestion did not ask for.

The pattern that works: autocomplete the street, then explicitly prompt for the unit when the selected address is a known multi unit building, and preserve exactly what the customer typed alongside the standardised version. When the two disagree, the customer's version is often the one the courier needs.

Verify the chain end to end

Test orders through your own checkout to multi unit addresses, a tower block, a business park suite, a basement flat, and inspect the final carrier label character by character. Validation quality is not a vendor claim, it is what survives your order feed, your warehouse system, and the carrier integration intact.

Track delivery failures by whether a unit was present in the order. That one cut of the data usually pays for the whole investigation in the first month.

Keep reading

Related guides on this site: Validating IBANs and Bank Details at Checkout: Check Digits Are Not Account Checks When to Validate: Inline, on Blur, or on Submit, and Why the Answer Is Per Field https://validatorwall.com/blog/index.md.

Frequently asked questions

Why do validated addresses still fail delivery?

Because validation can confirm the street address while the unit designator is dropped or normalised away between checkout, warehouse, and carrier label. The parcel then reaches the right building with no door to deliver to.

What is a unit designator?

The part of an address identifying the secondary unit: apartment, suite, unit, floor, or basement, with an identifier. Formats vary widely between what customers type and what postal databases store.

How can a checkout improve unit capture?

Use a clearly labelled secondary address field, prompt for a unit when the address is a known multi unit building, and preserve the customer's original entry alongside the standardised version through to the label.

See your own numbers.

A free bot-traffic audit shows the human-automated split in your live traffic - no code changes, no commitment.

Get a free bot-traffic audit

Do allowlists stop mint bots?

They stop the lazy ones. A strict allowlist with real verification, wallet age, activity history, or off-chain identity, filters out stages one and two. Determined operators buy or farm allowlisted wallets, which is why the allowlist is the start of the defense, not the whole of it.

Should mints just accept that bots will get some supply?

Some leakage is realistic, but 'accept' is the wrong frame. Every percentage point of supply that reaches real collectors instead of bots is community goodwill and secondary-market health. The projects that treat bot defense as ongoing maintenance keep more supply in the right hands than the ones that ship one check and move on.

>