The "Fast Lane" Answer
To find a quality address validation API, you need to understand that address validators don't aggregate their own data. We get our information from someone else's list. Kind of like fire trucks—we don't bring the water, we just put it to good use. So the quality of an address validator has less to do with what we might call the purity of the water, which is pretty universal, and more to do with how well we share what's coming through the hose. And the weapon of choice for blasting that water through the hose is an Application Program Interface, or API for short.
This article talks about APIs more generally (what they are, what separates the good from the bad, etc.). Some qualities, however, are unique to the industry of address validation, and they can make or break an address validation API. First of all, an address validation API must standardize an address prior to validating it. That means the API is performing two functions instead of one. After that, there's the consideration of how the API executes both of those functions.
Some features are variables that depend on your needs and budget constraints. Some, however, are measures of excellence that divide the sprinklers from the fire hoses. Here's a shortlist of things to consider when looking for a quality address validation API:
- Does the API use authoritative standards for its data?
- Does the API get frequent updates for their database?
- Does the API accept various inputs, both clean and unclean?
- Does the API utilize graceful degradation?
In short, a good address validation API will simply be a good API. If it does its job, integrates well into your systems, and doesn't break down often, you're off to a good start.
The "Scenic Route" Answer
What to Look For
Like any other API, it's wise to know something about the quality of a validation API before you commit to one. Because it's the combination of a tool and a service, both the validation and the API will have qualities unique to them, and both must be reputable for the final product to be worth using.
There are, however, some qualities unique to validation APIs that can help you identify whether what you're looking at is worth its salt or not. They break down into two major sections. The first section is "Standardization," the process by which addresses are cleaned up and prepared for validation, and the second is "Validation," where the addresses are actually checked for validity.
- Good Standardization: A validation API can't properly do it's job—comparing addresses against an authorized list—unless it can also standardize the data, so that it follows the same format as the authorized list. So a good validation API will standardize addresses. A great API will do it well.
- Authoritative standards: A good validation API will get its data straight from the source: in the US, for example, that's the United States Postal Service.
- Accepts Multiple Input Types: People use a variety of different systems to store their information, and most don't want to spend the manpower converting it to a different method or medium just so they can have the data processed. So a good validation API will accept multiple input types for address standardization, and then will do the work of putting it in the right format for the API.
- Accepts Dirty Data as well as Clean Data: Addresses submitted for validation can have a lot of problems. Sometimes things are misspelled. Sometime information is missing. Sometimes ZIP Codes or cities are wrong, etc. Sometimes we forget that computers, unlike humans, can't intuit our meaning. But with good programming, they can come close. A good validation API is written so that it doesn't just take "clean" data for validation, it can also take "dirty" data and clean it up.
- Authoritative: Similar to what's listed above, an address validation service is only as good as the source data they use to validate.
- Updated Frequently: Even if the list is authoritative, if it's 50 years old, the addresses are pretty much useless. Address data can change a lot over a short period of time, so a good API is tied to a well-kept database.
- Graceful Degradation: Good APIs will be able to scale down their output rather than cut it off outright. For example, watching a Youtube video is more enjoyable in HD, but the program wisely clocks down the output if bandwidth becomes a problem. First it scales down to lower quality outputs (720p, 480p, etc.). If that's still not enough, rather than show a grainy video, or failing altogether, it buffers. It gives the best output it can. With a validation API, it's the same way. The more information provided, the better. But the good ones can still offer you the best options for incomplete data, rather than offering nothing.
- Processes "Batches": A batch is just shorthand for a large group of something. In this case, a long list of addresses. Some APIs, like the one on the USPS website, only processes one at a time. Not very efficient if you're a shipping business with 50,000 clients. A good address validation API will be able to process a large number (or "batch") of addresses all in one go, then return the information to you once it's finished. Speed of batch processing varies by provider, but the option to process batches is pretty crucial unto itself.
- Useful Output: It probably sounds like a more generic API standard to have output in a format that's clear and useful, but hear us out. It's all fine and dandy when you only validate addresses one at a time, but when you process a batch as mentioned above, things get tricky. You need to be able to give them a huge list, and have the API understand it. Then you need it to work the other way around, with data coming back in a format that won't take days to sort through. Typically this involves exporting the list to a spreadsheet for you, but however the API does it, it needs to be as close to "plug-n-play" as possible.
What do I do now?
This list is a baseline. APIs that don't meet most of the requirements on this list are just not pumping out enough water to put out the fire, so to speak. There are attributes beyond this, as mentioned before, like speed, turnaround time, breadth of supplemental information etc. These things all become more applicable once individual needs are taken into account. But even if the API you're looking at has power windows and an attachment for making pasta, if it doesn't meet the standards above, it's not making the cut. If it can't do the basic, simple things well, how is it going to juggle all the fancy bells and whistles?
That's how you know you've got a good one. Simple first. Extravagant later.