Documentation

 

SmartyStreets vs. USPS: The Policy/Procedure Disconnect

Question

Hang on now! How come USPS Publication 28 section 215 establishes an addressing standard that SmartyStreets doesn’t follow for dual addresses? Doesn’t this amount to plain ol’ postal policy apostasy? The USPS is authoritative after all.

Answer

You are absolutely correct... and yet, also, incorrect. How so? Well, the short and sweet of it is that the USPS doesn’t practice what it preaches in regards to dual addresses. In their Pub. 28, it states that the preferred address should go just above the last line which contains the City/State/ZIP information. In practice, however, the preferred address goes at the top. How do we know that? Because that is how the USPS does it. Because more value is placed on actual practice than on written policy we have opted to adopt what is actually being done.

Below are a few responses to letters we’ve received regarding this disagreement between what SmartyStreets does and what USPS Pub. 28 says. If you look beyond the unavoidable redundancy among them, you will find the several valid aspects of the reasoning we used to decide to adhere to practice instead of the written policy.

SmartyStreets Clears the CASS Hurdle

"John, just because you are right, and there is full documentation showing how right you are, doesn't mean that is how it actually works. I have had to answer this question a number of times. It's frustrating that the USPS docs says it one way, their certification program handles it a different way, their clerks one way, and the actual mail carrier still another. In no way will I say that you are misunderstanding - It is confusing, to be sure.

Our service is CASS-Certified, which means that our output meets the USPS requirements for automation. It's very strict. If you were to put the best address right above the last line (City/State/ZIP Code line) it would throw off the clerks and carriers."

Lack Of Enforcement Legitimizes Common Practice

"...The fun thing is that this seems to be a policy on paper but not one that is enforced. Most people put the preferred address on the top, right under the name. You will get different answers from different postal employees at different post offices. That's confusing. But more confusing is that that policy in Pub. 28 is different (and not enforced) from what the public expects. In fact, there are quite a few postal regulations that go against what is commonly done, and it's not going to change. Preferring all uppercase, not gonna change. Eliminating all punctuation, like commas and apostrophes, not gonna happen."

Freedom to Restructure the Output

"Remember that we are not returning any specific layout but instead data fields that you can lay out in any way you like as you design your application.

If you wanted to have ZIP Code first, you could certainly do that as well. It's not recommended, but you could. Our output fields, Delivery Line 1 and Delivery Line 2 can certainly be arranged in any manner that you like."
"When we set up our service, we came to this discrepancy and had to decide to either follow their practices or their documentation. We decided to follow their practices as that is certainly the most reasonable thing to do…

I stand by the fact that the official USPS website even contradicts the USPS Pub. 28 specifications. So, where do you turn for the right way to do it when the authority states it one way and then implements it a different way?

We have instead opted for giving a suggestion based on what we have seen on the USPS website and what is in common use by the majority of the population. But, we also give you all the data and allow you to assemble it any way you like."

In conclusion, when SmartyStreets was faced with the decision of adhering to either USPS official policy or USPS common practice, we chose the path that most resembles that place where the rubber hits the road. After all, the one guy who doggedly persists in standing backwards at the front of a packed elevator is not the guy whose judgement you implicitly trust.