Our service averages 100% uptime with sub-30 millisecond response time. (Self-hosted, on-premises, on-site, local solution available)
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.
We guarantee 99.98% uptime and sub-500 millisecond response times. We'll compensate by granting service credits if those guarantees are not met.
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.
Our legal definition of an "outage" is any five-minute period when you can't talk to our servers.
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.
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.
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).
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 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.)
Reuse established HTTPS connections because it's way faster. It's not our fault if you don't.
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.
HTTPS isn't very reliable by itself. Be prepared to send a request more than once to make sure it arrives.
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.
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.
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.
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.
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.
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.
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:
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.
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:
Updated: August 4, 2015