The following document outlines the minimum guarantees offered to subscribers of the LiveAddress API 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 geo-distributed solution between multiple data centers strategically located around the United States.
Our service averages 100% uptime with sub-30ms response time.
SmartyStreets guarantees at least 99.98% availability across all LiveAddress API servers at all times 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 (lookups) will be issued the accounts of the affected users.
We guarantee 99.98% uptime and sub-500 millisecond response times. We'll compensate by granting lookups if those guarantees are not met.
Web Service Availability Guarantee
SmartyStreets guarantees its LiveAddress API 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 LiveAddress API web service for five consecutive minutes.
Our legal definition of an "outage" is any five-minute period where 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 document, "response time failure" is defined as a period of time when the web service takes longer than 500 milliseconds to respond to a SINGLE address request (excluding any Internet latency) during five consecutive minutes. Requests which package multiple addresses may take slightly longer to service for each additional address.
Excluding Internet latency (the time it takes for a packet to get from your machine to ours), we will always answer within half a second.
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. Internal latency is defined as how long it takes the LiveAddress API system to interpret a request and return a sensible response. Internet latency is something over which SmartyStreets has absolutely no control (such as a 3G iPhone cellular connection from Japan) and which is expressly excluded in this agreement.
Actual LiveAddress API latency can be calculated by establishing a persistent HTTP/S connection, issuing a single request over that connection, and then subtracting the ping time to that IP address. Keep in mind that setting up a new HTTP/S connection is a costly operation that may require multiple round trips between the calling code and the LiveAddress API servers (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/S connection is established between calling code and the LiveAddress API servers. Specifically, HTTP/S exists on top of TCP which requires a minimum 3-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. 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/S 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 may dramatically improve response times. 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 HTTP/S connections because it's way faster. It's not our fault if you don't.
Inherent in the HTTP/S 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 LiveAddress API server are transported using HTTP/S over unreliable networks, any single failure cannot accurately predict and/or conclusively demonstrate a network outage or response time failure. Similarly, HTTP/S and the underlying TCP protocol 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.
HTTP/S 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, tropical storms knocking out electrical power, Internet backbone provider outages, various kinds of provider equipment failure, or any other number of factors beyond the control of SmartyStreets. It is primarily for for these reasons that there are three fully independent data centers from no less than two data center operators running at any given time.
Code calling into one or more LiveAddress API servers must be able to handle failure of a given data center by removing any failed IPs from the request rotation. Any such data center outage is excluded from the availability and latency guarantees offered within this agreement so long as at least one data center remains operational and able to service 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 LiveAddress API servers individually and collectively (from no fewer than six separate locations around North America) track various critical server metrics. It is from these independent statistical reports that collective server uptime and downtime is calculated for the purposes of credit calculation.
We monitor our servers using at least two, independent 3rd-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 LiveAddress API, or any other LiveAddress API 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 LiveAddress API;
- that result from any action or inaction of you or any third party;
- that result from your equipment, software or other technology and/or third party equipment, software or other technology (other than third party equipment within our direct control); or
- arising from our suspension and termination of your right to use LiveAddress API in accordance with the Terms of Service.
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 LiveAddress API service to the account;
- in the case of a "web service outage" resulting in less than 99.98% uptime (but at least 99%), SmartyStreets will grant a credit of one (1) additional week of LiveAddress API service to the account;
- in the case of a "web service outage" resulting in less than 99% uptime, SmartyStreets will grant a credit of one (1) additional month of LiveAddress API service to the account.
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 upon the severity of the outage.
Updated: October 24, 2012