Is Smarty Down Right Now? Check if there is a current outage ongoing.

We discovered that the "API Keys" page in our Account dashboard web site was not able to retrieve the lists of keys from the backend service. This has now been fixed.

We discovered that the "API Keys" page in our Account dashboard web site was not able to retrieve the lists of keys from the backend service. This has now been fixed.

Around 19:10 UTC, increased traffic exposed resource limitations caused by a previously implemented algorithm update, leading to issues on several servers hosting some of our services (US Street API, US Extract API) in one of our data centers due to insufficient RAM. To ensure stability and service reliability, the affected servers have been decommissioned and replaced with upgraded hardware.

Around 19:10 UTC, increased traffic exposed resource limitations caused by a previously implemented algorithm update, leading to issues on several servers hosting some of our services (US Street API, US Extract API) in one of our data centers due to insufficient RAM. To ensure stability and service reliability, the affected servers have been decommissioned and replaced with upgraded hardware.

The US Enrichment API intermittently returned HTTP 500 codes in a single data center on 2025 February 26 around 17:00 UTC. The issue has been resolved as of 17:35 UTC.

Around 18:00 UTC, one of our facilities experienced a network routing issue that lasted for about 30 minutes. The facility was removed from DNS rotation until the network issue had been resolved. If you have not yet read through our "Technical Requirements" and "Best Practices" documentation, this could be a good opportunity to become familiar with those important and helpful documents. - https://www.smarty.com/docs/cloud/requirements#retry - https://www.smarty.com/docs/cloud/best-practices

From 01/08 12pm UTC to 01/09 9am UTC some requests to the US Street [Address] API instances experienced an intermittent issue with certain malformed addresses that caused some requests to not get a response, returning HTTP 503 errors to those requests. This affected a small number of requests and the error has since been resolved.

During a regular upgrade of our control plane, several controller nodes became unresponsive. This resulted in various routing issues which were manifest by intermittent HTTP 503 errors visible in the HTTP response to some callers. Our monitoring systems alerted our Operations Engineering Team of the anomaly and, as a result, the affected cluster, located in our US Central region (Chicago), was immediately removed from production rotation. The affected cluster has been restored to full health by provisioning new cloud resources using our IaC (infrastructure as code) systems. Following this, the cluster was confirmed to be was healthy via our automated monitoring and was subsequently re-introduced into active rotation.

On 2024 December 19, around 22-24:00 UTC, some users may have received the HTTP 299 code in response to requests from one of our loadbalancers. The reason for this response has been identified and remediated. We would like to take this opportunity to remind our users to familiarize themselves with our best practices. https://www.smarty.com/docs/cloud/best-practices

Around 15:00 (3pm) UTC on 2024 November 28, a single IP address at one of our datacenters experienced a routing issue that caused some requests to be "null routed", which may have resulted in some clients experiencing 500 level errors during that time. This issue persisted until 17:00 (5pm) UTC on 2024 November 28, at which time our upstream provider resolved the issue. Our recommendation to clients to mitigate an issue such as this in the future is to maintain a pool of active TCP connections to the server nodes and to only send traffic over active, healthy TCP connections. Then a background "thread" (or programmatic equivalent) could attempt to connect to the suspect IPv4 address. Once that connection has determined to be healthy, regular traffic can be resumed over that TCP connection.

As previously announced, JSONP support in US Autocomplete Pro API is being removed today. See previous announcements: - https://status.smarty.com/incidents/hftb2zdrfn3q - https://status.smarty.com/incidents/m8pc40fcq3c5

No. We have evaluated our systems and determined that we are not at risk.

A configuration change to an older version of International Address Autocomplete API caused a few users to receive inaccurate 402 responses. The configuration was identified and rectified. Users of the older version of this API should no longer be receiving the erroneous response. Users of the new version of the API were unaffected.

Some modifications were made to TLS certification configurations on one of our load-balancers. Part of the modification adjusted the order in which certificates were presented to clients. Older applications that are unable to properly use Server Name Indication may have been affected adversely by this change. In order to continue supporting older clients, the certificate order was readjusted to maximize compatibility. We suggest updating any applications that call Smarty APIs to be compatible with modern TLS certificate usage. We also suggest ensuring that the hostnames being used in requests to our APIs are current. Hostnames can be found on the documentation pages for the products that you are using. (https://www.smarty.com/docs/cloud)

During a regularly scheduled deployment of an update to our US Address Verification API and US Address Autocomplete API in one of our datacenters, a misconfiguration caused the services to not respond properly. The problem was quickly observed and remedied.

On 2024 January 22 US Street Address API experienced some unexpected resource constraints that briefly caused a few intermittent 503 errors for a handful of customers. These restraints have been resolved.

As previously announced, JSONP support in US Street Address API is being removed today.

A new endpoint with new capabilities has been released. As a result of this change, the older (existing) endpoint is being deprecated and will be removed from service. Please see our documentation regarding this mandatory and breaking changes: - https://get.smarty.com/intl-autocomplete-migrate - https://www.smarty.com/docs/cloud/international-address-autocomplete-api

JSONP is officially deprecated. Support will be removed for JSONP starting on 2024 January 31.

During the last three days we have been observing a significant increase in CPU utilization of various application servers. As a result of this CPU utilization, we made some adjustments to the software running our proxy API servers to better watch for traffic causing the CPU spikes. As part of this remediation effort, at 2023-11-05 00:54 UTC, a new version of our proxy API with this new behavior was deployed to a single cluster. After the “canary” release appeared to be functioning correctly according to available metrics, we rolled the change out to a second cluster roughly 15 minutes later. Finally, roughly 21 hours later, at 2023-11-05 21:45 UTC nearly, we rolled out the change to the remaining third cluster. At 2023-11-06 01:40 UTC, we received notice from approximately four different customers of some intermittent issues wherein an HTTP request to our US Street API (https://us-street.api.smarty.com) would return an HTTP 400 response status. Within five minutes after that notice, at 2023-11-06 01:45 UTC, we rolled back the above changes to a working version of the proxy API across our entire fleet. Since that time, the underlying bug within the proxy API introduced and originally deployed at 2023-11-05 00:54 UTC was resolved and a new version of the software that is unaffected by this issue was deployed to a single cluster today at 2023-11-06 16:50 UTC. Additional tests and monitoring have been put in place to proactively watch for similar kinds of issues in the future.

One of our IP addresses became unresponsive. Investigation showed that the IP was configured properly, however the connection of the IP, to the load balancer to which it was assigned, was incomplete. This situation started when one of our nodes went offline and the IP was automatically assigned to a different node (a common and normal occurrence). When the node that went offline came back online, the IP was reassigned to the original node (also normal). While the assignment was correctly executed, the IP provider did not properly complete the routing of traffic (abnormal and unusual). As we do not control the IP routing at the provider level, we are implementing additional monitoring checks that will allow us to detect and mitigate this unusual situation in the future.

Some customers experienced an occasional 404 "Not Found" error with the new update that we pushed yesterday afternoon to one server set and rolled back this morning. This was due to some requests formatted with a slash after the route "street-address/". e.g. "https://us-street.api.smartystreets.com/street-address/?input_id" vs. "https://us-street.api.smartystreets.com/street-address?input_id". This was not recognized correctly in the new update and will be corrected.

Between Apr 18, 2023 2:30pm and Apr 19, 2023 10:30am the us-autocomplete-api was not grouping sub-units (apartments, suites and so forth). This has been corrected.

We have identified and rectified the code which was causing collisions in certain cases. We've also introduced enhanced testing measures to ensure such situations are avoided moving forward.

On Friday we deployed a minor system update. Beginning on Monday morning a few customers reported inconsistencies in the International Street Address API output. We rolled back the update and the inconsistencies have stopped. We are still investigating the root cause.

A new IP address was introduced into our infrastructure for one of our facilities and a previous IP address was phased out of use. Part of this process involved updating DNS records. All appropriate records were updated with the exception of several legacy hostnames, which were overlooked. This resulted in a few users seeing intermittent request failures when requests resolved to the previous IP address. This only affected one of our facilities. All other facilities maintained full accessibility. The aforementioned hostnames have now been updated.

On April 17, 2023 the current certificate for *.api.smartystreets.com will expire. This certificate was issued by Sectigo (previously known as Comodo) and is chained to the root certificate "USERTrust RSA Certification Authority". On March 21, 2023 at 12pm Eastern Time (approximately 2 weeks hence), we will begin the process of rotating out this soon-to-expire certificate with a newer certificate issued by a service chained to one of our trusted certificate authorities, as listed in our documentation [1]. Specifically, we intend to begin using certificates issued by various ACME-compliant certificate providers. In this case we will begin using certificates with the industry standard 90-day expiration from a company called ZeroSSL. These new certificates will continue to be chained to the same root CA as our soon-to-expire certificate issued by Sectigo. Following this, on April 18, 2023 we will begin to introduce certificates issued by Let’s Encrypt (chained to “ISRG Root X1”) and Google (chained to various "GTS Root" certificates). FAQ: Q: Will I need to take any action? A: If you are "pinning" our certificate (meaning hard coding the certificate into your application, runtime (e.g. Java), or operating system "trust store"), yes. Please be aware that our certificates will now rotate on a much more frequent basis. In the past, the certificates were rotated yearly. Now they will be rotated at least every 60 days and often as frequently as every 30 days. Further, if you are manually curating which root certificate authorities you allow into your trust store, you will need to ensure that those listed in our documentation [1] are added to your trust store. Q: Why rotate the certificates so frequently? Isn’t that insecure? A: It is considered an industry best practice to rotate certificates as frequently as reasonably possible. Doing so actually increases security and drastically decreases the likelihood of private key exposure. All automated (ACME-based) certificate providers typically have certificates expire after 90 days. In fact, in 2020 Apple began to enforce a 397 day limit on all certificates meaning that those with an expiration longer than 1 year and 1 month would be considered invalid. In other words, certificates with longer expiration dates are now considered to be less secure than those with shorter expiration dates. Q: What if I have more questions. A: Please reach out to our support team for further clarification if you have any questions on the matter. References: [1] https://www.smarty.com/docs/cloud/requirements#trusted-authorities

Between 2023 January 16 and 2023 February 07, the US Rooftop Geocoding API returned inaccurate geocodes for a small set of addresses that were designated with a rooftop, parcel, or street-level geocode precision. The following addresses were affected: - non-postal - USPS R7 - non-postal addresses that became postal addresses before 2023 January 16 The issue occurred due to incorrect temporary keys used to associate non-postal addresses to geocodes during the data build. The problem has been resolved and measures have been implemented to prevent this from happening in the future. Based on analysis, the inaccurate geocodes would likely have affected about 1.4% of the addresses processed by our clients.

During a routine rotation of TLS certificates on our load balancers, a single load balancer in a single facility did not update properly. That instance was manually rotated to pick up the change.

A new version of International Street API was inadvertently released which had an issue causing a health check failure after multiple hours of time, which caused traffic to direct away from the instance. The health check monitor did not completely restart the affected system, resulting in the failure remaining indefinitely. The version was corrected and the health check monitor is being updated to mitigate future recurrences.

During the night the International Street API service had intermittent connectivity problems. We believe we have identified the problem and implemented a fix.

The deprecated US Autocomplete API service underwent the process of termination over the course of yesterday and today. During the process, a few intermittent 503 responses were reported from customer who were still using the old address for calling the API. The address has been updated to send traffic to the US Autocomplete Pro API service. The update process for one of the loadbalancers handling that transition was out of sync. The problem was identified and remedied.

The problem was found and corrected. All datacenters are fully operational again.

The issue has been identified and a fix is being implemented.

In two of our datacenters, our International Street API service is in a degraded state. We are currently investigating.

Due to a recent security update in one of our data centers, several, of the many, instances of our US Extract API service started experiencing transient failures. This inconsistent misbehavior resulted in some requests returning 503 errors. On Tuesday 29 October 2019 we were able to identify the problem and implement a solution. After monitoring for more than 24 hours without further incident we feel confident that the solution was successful.

We released a version of US Zip Code API today that did not play nice with the demo tool on our website due to a CORS misconfiguration. The problem was identified and quickly rolled back.

Today between 13:40 and 14:10 UTC the DNS for our public website was updated. During the transition the website may have appeared to be unavailable. The process was completed successfully and all systems appear to be nominal.

Beginning tomorrow (Tuesday 21 January 2020 at 11:00 AM Eastern Time), our APIs will only accept client connections using TLSv1.2 or greater. Clients using TLSv1.0 or TLSv1.1 will no longer be able to connect. An email broadcast was previously sent on this topic and all new signups since that broadcast have been notified as part of the new customer registration email message. For more information see: https://smartystreets.com/blog/2019/10/removing-old-versions-of-tls To see the version you are connecting with, see: https://test-tls.api.smartystreets.com

Yesterday, Tuesday 21 January 2020 at 11:00 (AM) Eastern Time / 09:00 (AM) Mountain Time, in accordance with announcements we have made leading up to this day, we disabled acceptance of TLSv1.0 or TLSv1.1 connections to all of our APIs. Yesterday, Tuesday 21 January 2020 at 18:00 Eastern Time and 16:00 Mountain Time, we re-enabled acceptance of TLSv1.0 or TLSv1.1 connections to all of our APIs. We did this as a courtesy to those who are still in the process of upgrading their clients to be able to connect using TLSv1.2 or greater. Today we will be repeating this shutdown. Clients connecting to our APIs today between 11:00 (AM) Eastern Time / 09:00 (AM) Mountain Time and 18:00 Eastern Time / 16:00 Mountain Time will be rejected if their connections are using TLSv1.0 or TLSv1.1. An email broadcast was previously sent on this topic and all new signups since that broadcast have been notified as part of the new customer registration email message. For more information see: https://smartystreets.com/blog/2019/10/removing-old-versions-of-tls To see the version you are connecting with, see: https://test-tls.api.smartystreets.com

Following the plan for permanently retiring support for TLSv1.0 and v1.1 we have concluded our initial temporary shutoff which began on Tuesday, January 21, 2020 at 11:00am until and through Wednesday, January 22 at 4:00pm. As of January 22, 2020 at 4:00pm all systems are now running in full-compatibility mode, meaning that they are accepting TLSv1.0 and above. The next step in retiring support for TLSv1.0 will begin on Tuesday, February 4, 2020 at 9:30am and will concluded at 11:30am the same day wherein any requests utilizing TLSv1.0 or TLSv1.1 will be rejected. NOTE: All times are Mountain Time (MST) unless otherwise indicated. NOTE: Our clients who are having the greatest difficulty are running Windows Server 2012r2 (or earlier) along with .Net 4.0 (or earlier). This Microsoft article (suggesting .Net 4.7) has been helpful for many: https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls

On Tuesday 04 February 2020, at 09:30 (am) Mountain Time, acceptance of requests using TLS versions 1.0 and 1.1 will be disabled. They will remain disabled until 11:30 (am) Mountain time of the same day, for a total of two hours. If you are unsure whether your application and traffic will be affected, please point your application to our test tool: https://test-tls.api.smartystreets.com/ For more information, see the following blog post: https://smartystreets.com/blog/2019/10/removing-old-versions-of-tls

A small number of customers were affected by a deployment to a single facility wherein the configuration did not contain all legacy domain names for various services. For example, the official domain name for the US Street API service is: https://us-street.api.smartystreets.com/ An older (legacy) domain name for the same service is: https://api.smartystreets.com Further, this same issue touches a handful of other services including: us-extract.api.smartystreets.com (legacy: extract-beta.api.smartystreets.com) us-autocomplete.api.smartystreets.com (legacy: autocomplete.api.smartystreets.com) The issue was manifest from 9:00 AM Eastern Time until 10:15 AM Eastern Time, at which time the configuration was rolled back pending review. Further, various automated tools which conduct systems test are being updated to verify legacy domain name compatibility.

During the upgrade of one of our datacenters, the Forward Proxy API in that datacenter was unavailable. The service outage was brief. The service is back to 100%.

On Tuesday 18 February 2020 at 16:30 UTC (11:30 ET, 09:30 MT) we will be shutting down all support for TLS v1.0 and v1.1. This shutdown will be final.

For approximately 12 hours hours spanning from yesterday through this morning a number of addresses submitted for validation to our International Street Address API for GBR (United Kingdom/Great Britain) FRA (France) and JPN (Japan) were failing. The issue was corrected at 7:30am Mountain Time / 9:00am Eastern Time. We have identified the root cause of the issue related to the data build process from our partner data feeds. We are in the process of expanding the integrity checks run on each data feed to further ensure correctness of the data.

The final shutdown of support for TLS v1.0 and v1.1 has been completed across all SmartyStreets APIs and services. From this point on we will only accept connections that use TLSv1.2 and above.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The TLS certificate we are using is based upon a cross-signed root certificate issued by Comodo. One of the trust pathways expired at around 7:00AM Eastern Time today. The expired trust pathway has been mitigated in modern and updated software systems including web browsers and operating systems. A handful of clients using older (often unmaintained or unsupported) operating systems and versions including RedHat Linux 4.x or old versions of libcurl and OpenSSL) have been experiencing connectivity issues because updates to root certificates were not available on these older systems. As a mitigating effort, we identified a third possible trust pathway that many of these older clients might be able to utilize with our cross-signed certificate and we added the appropriate intermediate certificates in the chain in order to allow that alternate pathway to be utilized so long as the additional certificate authority (AAA Certificate Services, expiration 2028) is trusted by the system. For clients that continue to experience ongoing TLS connectivity issues, the only other possible alternative at this point is to manually add the newer version of the AddTrust Certificate Authority to your system "trust store" location: https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020 For additional information on the certificate chain, please utilize the SSL Labs report found here: https://www.ssllabs.com/ssltest/analyze.html?d=api.smartystreets.com&hideResults=on

A preliminary analysis appears to show that this is affecting systems which are using an older "root certificate". We are researching the best way to help users mitigate the issue. There appear to be other reports about this on other services as well: https://security.stackexchange.com/questions/232445/https-connection-to-specific-sites-fail-with-curl-on-macos/232448#comment475027_232446

We are investigating reports of users receiving TLS certificate validity errors.

Around 10:45 MT, our website experienced some intermittent connectivity this morning for about 15 minutes. This was caused by some problems that our CDN provider was having. None of our APIs were affected.

Around 11:30 MDT some services were upgraded in one of our data centers. This may have caused some customers to experience a momentary connection problem if their requests were pointing to that data center at the time. The situation has been resolved.

One of the datacenters that we use was exhibiting an above average latency. That datacenter has been removed from service until the latency issue is resolved.

The update is complete.

The TLS certificate for our API services has been renewed. The updated certificate will be rolled out to all of our services over the next 24 hours. The updated certificate has a new root path. For details on our Trusted Certificate Authorities, review our requirements page: https://smartystreets.com/docs/cloud/requirements#trusted-authorities

During the course of a slow rollout of a newly rewritten authentication component, the software was deployed with an unintended bug which prevented the usual proxying of requests to the intended back-end service. The cause of the failure is due to an oversight on our part to register an old/legacy domain names still in use by affected customers (autocomplete-api.smartystreets.com as well as extract-beta.api.smartystreets.com). We have since re-added support for these domains and will continue with our slow rollout. Customers should update to the canonical hostnames for respective services (us-autocomplete.api.smartystreets.com and us-extract.api.smartystreets.com).

During Thursday 11 March 2020 and Saturday 13 March 2020 we noticed higher than normal latencies in our International Street API endpoint in two of our facilities. The problem was found to be coming where the default configuration in these specific facilities used slower, magnetic hard disk drives (HDD) instead of faster, solid state drives (SSD). This combined with a large influx of new requests from customers to cause the latency. The servers were quickly changed to all use solid state drives and the latency returned to normal. We have updated the configuration to explicitly require high-performance solid-state drives for the International Street API endpoint.

This issue has been resolved.

All systems are operational. We are still monitoring.

We are continuing to monitor for any further issues.

The problem is related to third-party DNS issues. We have implemented a temporary change which bypasses the failing DNS.

Our website is currently down. We are working to resolve the problem as quickly as possible. Our API services are unaffected..

As of 14:25 (Mountain Time) today we migrated one of our facilities (US West Coast) to a new IP address. This update should not affect any of our customers that are following our recommended Technical Requirements (https://www.smartystreets.com/docs/cloud/requirements). Any customers who are hard-coding our IP addresses, without going through our Forward Proxy API (https://www.smartystreets.com/docs/cloud/forward-proxy-api), could be affected adversely.