This is an archived page. The information on this archived page is no longer current.
Why is there additional validation happening?
QuestionLast Updated: March 26, 2013
We have 5 fields for address entry: Street1, Street2, City, State, and ZIPCode.
People generally put the apartment number in Street 2. For example:
5200 MEADOWCREEK DR APT 2011 Dallas TX 75248
Now, when SmartyStreets processes this, it moves the apartment number back up into the street1 line. I'd rather it didn't (I have read this: Address one line), but for now I'm okay with it as we've found another issue.
When we pre-fill these controls with the address as SmartyStreets returned, for example:
Street1: 5200 MEADOWCREEK DR APT 2011 Street2: City: DALLAS State: TX Zip: 75248-4054
On page load, the SmartyStreets address selector UI displays <- this is the odd part.
If, however, I remove the apartment number from the address then the UI doesn't display because the address was valid to begin with.
It seems like something is saying the address isn't valid... but then it is.
The raw response from our servers indicates that this address could only be DPV confirmed by dropping (ignoring) the secondary information, which is the apartment info in this case (DPV Return Code of "S"). This is probably because the apartment numbers were established internally by whatever organization resides at that address and aren't yet recognized by the USPS. Secondary information (and stuff that gets put in the Street 2 field) usually only serves to help the mail carrier and so it usually isn't removed, even if it's ignored in the verification process. The other question you referenced explains how the USPS likes to standardize the delivery line with secondary info on line one.
So, here's what probably happened:
- Address was submitted with secondary info on line 2
- Verification process moved the secondary info into line 1 and address was DPV confirmed by dropping (ignoring) the secondary info
- Address was submitted with secondary info on line 1
- Address was DPV confirmed by dropping (ignoring) the secondary
You have exposed one of the limitations of our current API— we tell you if the address is good or bad but not how good/bad and why. Stay tuned for future releases of the software. This stuff really is on our mind and we have plans to address it in more overt, understandable ways.