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-premise, local solution for customers who desire it.
Our service averages 100% uptime with sub-30 millisecond response time. (Self-hosted, on-premise, on-site, local solution available)
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.
We guarantee 99.98% uptime and sub-500 millisecond response times. We'll compensate by granting service credits if those guarantees are not met.
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.
Our legal definition of an "outage" is any five-minute period when you can't talk to our servers.
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).
Excluding Internet latency (the time it takes for a packet to travel between your machine and ours), we will always answer within half a second for individual lookups.
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.)
We guarantee performance for equipment we control, not for networks we can't control. We can't control Internet latency because we don't own the Internet (yet).
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.
Reuse established HTTPS connections because it's way faster. It's not our fault if you don't.
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.
HTTPS isn't very reliable by itself. Be prepared to send a request more than once to make sure it arrives.
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.
For best results, don't send requests to IP addresses directly; let DNS resolve the best server for you, since specific IPs may go down from time to time or be swapped out entirely.
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.
We monitor our servers using at least two independent, third-party services. When we calculate downtime, we always use the metrics offered by both monitoring tools.
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;
- 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.
Your account must be current, active, and in good standing to be eligible for service from us and the associated guarantees. If you fail to take action to maintain service, or take some action to disrupt service, the SLA does not apply.
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.
If the Service is ever unavailable according to the above terms, we will award you between one day and one month's worth of service, depending on the severity of the outage.
Updated: August 4, 2015