Service Level Agreement


The following document outlines the minimum guarantees offered to subscribers of the US Street Address Verification API service (herein: Service) and the remedies offered if those guarantees are not met.

In practice, we have a much higher actual value than what is guaranteed in this document. Specifically, our uptime has been 100% with a corresponding average response time of 30 milliseconds (excluding Internet latency) because we offer a fully redundant solution, geo-distributed between multiple data centers strategically located around the United States. Additionally, we offer a self-hosted, on-site, on-premises, local solution for customers who desire it.


SmartyStreets guarantees at least 99.98% availability for the Service and takes appropriate precautions to ensure that any one user on the system does not adversely affect any other user in causing response times to rise above a 500 millisecond threshold (excluding Internet latency). In the event that these levels are not maintained as provided herein, service credits will be issued to the accounts of the affected users.

Web Service Availability Guarantee

SmartyStreets guarantees the Service will be available no less than 99.98% during a given calendar month. For the purposes of this document, a "web service outage" is defined as a period of time during which no traffic can ingress or egress from all instances of the intended Service for five consecutive minutes.

Response Time Guarantee

SmartyStreets strives to ensure that all requests are processed in a timely fashion and, to this end, utilizes various techniques to offload and balance traffic to all available physical servers. For the purposes of this agreement, "response time failure" occurs if, during five consecutive minutes, the Service takes longer than 500 milliseconds to respond to a single address lookup (excluding any Internet latency).

Internet Latency

Internet latency is defined as the amount of time it takes for a given request to receive a response when travelling over a public network, whereas internal or application latency is defined as how long it takes the Service to interpret a request and return a response. Internet latency is something over which SmartyStreets has absolutely no control (such as a 3G iPhone cellular connection from Africa) and is expressly excluded in this agreement.

Application latency can be roughly calculated by establishing a persistent HTTP connection, issuing a single request over that connection, and then subtracting the ping time to that particular machine instance of the Service. Keep in mind that setting up a secure HTTP connection is a costly operation that requires multiple round trips between the calling code and the machine on which the Service is running. (See below.)

HTTPS Handshakes

Internet latency is visible when a new HTTP connection is established between calling code and the application servers. Specifically, HTTP exists on top of TCP and requires a minimum three-way handshake to establish a connection between two parties. Pure HTTP then sends a stream of packets and receives a stream of response packets with ordering and retransmission of lost packets occurring from time to time due to network congestion and factors that affect packet loss and are beyond our control. (Again, think cellular connection in the middle of Africa.) HTTP on TLS (HTTPS) compounds the Internet latency visibility because of an additional set of handshakes that occur when asserting the identity of the server and establishing a "shared secret" between the two parties.

For best results, maintain a pool of pre-established "keep-alive" HTTP connections and then balance requests across connections within that pool. Although this step is not required and may not be advantageous for a given use case, it will dramatically improve response times by avoiding the connection handshake. In addition, if the calling code supports "HTTP pipelining" or the ability to issue multiple requests over a single connection simultaneously, performance can be further improved.

Network Failures

Inherent in the TCP protocol design is a probability of failure. The canonical example of this is where one or more images fail to load when viewing any given website in a browser, and where a simple page refresh "fixes" the problem.

Because requests to and responses from the Service are transported over unreliable networks, any single request or response failure cannot accurately predict and/or conclusively demonstrate a network outage or response time failure. Similarly, the HTTP and TCP protocols provide no quality of service guarantees over a public network such as the Internet or cellular networks. Therefore, it is only in the aggregate that a failure in availability or response time can be truly detected.

Data Center Outages

From time to time, a given data center may become completely unavailable for any number of reasons such as construction crews severing physical cables, storms knocking out electrical power, Internet backbone provider outages, various kinds of network operator equipment congestion and/or failures, or any other number of factors beyond the control of SmartyStreets. It is primarily for these reasons that we utilize multiple, fully independent data centers from no less than two data center operators running at any given time.

Any code calling into one or more instances of the Service must be able to handle complete loss of a given data center by removing any failed IPs from the request rotation. Any such data center or network operator outage is expressly excluded from the availability and latency guarantees offered within this agreement so long as at least one data center remains operational and able to process requests according to the tolerances set forth herein.

For absolute best performance, the calling code should maintain a pool of pre-established connections open to multiple data centers and then balance requests across the pool.

Server Monitoring

SmartyStreets currently utilizes no less than two independent monitoring services, each of which monitors each application server individually and the Service collectively (from no fewer than six separate locations around North America), in order to track various critical server metrics. We also employ application monitoring agents running on the application servers themselves. It is from the statistical reports provided by these agents that collective server uptime and downtime is calculated for the purposes of credit calculation.


The uptime and response guarantees set forth above do not apply to any unavailability, suspension, or termination of Service, or any other Service performance issues:

  • that result from a suspension of an account;
  • caused by factors outside of our reasonable control, including any force majeure event or Internet access or related problems beyond the demarcation point of the Service such as acts of war, terrorism and foreign enemies, natural disaster of overwhelming proportions, grand-scale discontinuation of electrical supply, or any other unforeseeable circumstances beyond the control of the Parties against which it would have been unreasonable for the affected party to take precautions and which the affected party cannot avoid even by using its best efforts;
  • that result from any action or inaction of you or any third party;
  • that result from your equipment, software, other technology, and/or third party equipment (other than third party equipment within our direct control);
  • arising from our suspension or termination of your right to use the Service in accordance with the Terms of Service; or
  • that result from your failure to adhere to the Technical Requirements page listed in our documentation.

Calculation of Credit

If SmartyStreets fails to meet the uptime and response guarantees set forth herein, SmartyStreets will apply service credits to the affected accounts according to the following schedule:

  • In the case of a "response time failure," SmartyStreets will grant one (1) additional day of the Service to the account at the current user plan. For example, if a customer has a "500 lookups per month" plan and experiences a response time failure, we will grant an additional 500 lookups valid for only one day.
  • In the case of a "web service outage" resulting in less than 99.98% uptime (but at least 99%) during a given calendar month, SmartyStreets will grant a credit of one (1) additional week of the Service to the account at the current plan.
  • In the case of a "web service outage" resulting in less than 99% uptime during a given calendar month, SmartyStreets will grant a credit of one (1) additional month of the Service to the account at the current plan.

Updated: August 4, 2015

The leader in location data intelligence

Ready to get started?