SSL certificates are a very important part of the internet. These certificates allow encrypted communication between your browser and https://zapier.com. They also allow your browser to guarantee you're actually looking at the webpage we intended. Both of these details disable would-be attackers from snooping on your private browsing or business data.
SSL certificates are also widely used when dealing with APIs. The same technology that lets your computer's browser talk securely to https://zapier.com also allows Zapier to talk securely to other web services (like Gmail, Salesforce, or Zendesk) in order to access your data on your behalf.
In order for SSL certificates to work, both parties (ie. your browser and https://zapier.com) must "trust" an independent third-party, known as a Certificate Authority (CA), who signs every SSL certificate they issue.
There are hundreds of CAs on the internet. In fact, for SSL to work properly, this list of CAs both parties "trust" must be continually updated -- an onerous detail.
So how does this all apply to Zapier?
Sometimes, services on Zapier allow you to specify your own domain (like Desk, JIRA, SugarCRM, Magento). In most cases, it's required that your domain have it's own SSL certificate for API communication to take place. More importantly, Zapier has to trust the CA that signed your SSL cerificate!
And here lies the crux of the problem. Sometimes, you'll purchase an SSL certificate that is issued by a CA that Zapier doesn't trust. Not because anything is wrong, but because we simply don't have the CA that signed your certificate listed.
You might see this type of error when adding a new account to Zapier:
We've introduced a new option to your user profile settings, that allows you to disable SSL cerificate security checks. Essentially, this means both parties (your server and Zapier) don't have to trust the CA in order for communication to take place. You'll still need a signed SSL certificate, but we won't enforce that it is valid.
WARNING: You should only do this as a last resort. Disabling these checks may enable an attacker to manipulate the data sent to Zapier or eavesdrop on data sent out of Zapier to websites with said SSL certificates. If you disable checks and adding an account still yields an SSL error, we highly recommend you revert the option back to enabled then contact support and we can debug further.
NOTE: We are respecting this "disable" option on a case by case basis for services. If you come across a service where you're still hitting SSL errors even after disabling the check, let us know.
NOTE: An "SSL" error doesn't necessarily imply a certificate problem. For example: "SSLERROR: The read operation timed out" is actually not a certificate problem. This error simply indicates the remote server didn't respond to our requests in a timely manner.
Please don't hesitate to contact us if you have any questions regarding this topic.
Recently, I took a breather my from usual frontend antics to add a new API to Zapier (this is apparently what I do for fun these days). Despite my sluggish internet connection and unscripted first-take, it only took 30 minutes to add Lockitron to Zapier. One episode of Arrested Development later -- Lockitron can now integrate with over 180 web services.
I'll chock this impressive feat up to the simplicity and obviousness of Lockitron's API and our developer platform.
MSSQL (SQL Server) is a bit tricky to get set up properly with Zapier. Our servers run Linux and we have a fickle driver stack to properly communicate with extenal MSSQL instances. In many instances, it is random whether or not a certain instance will work with Zapier. Here is a short list of compatibility if everything else is set up correctly:
SQL SERVER 2005 - NOT COMPATIBLE
SQL SERVER 2008, 2008 R2 - MAYBE COMPATIBLE
SQL SERVER 2010 - MAYBE COMPATIBLE
The first thing you can try is adding your MSSQL instance plain. Here is what that looks like:
Most importantly, you'll need to make sure your MSSQL instance is available outside your firewall. A popular request is IP white-listing. However, because Zapier runs on Amazon AWS, we do not have a single IP address, so this is not feasible.
If you are able to get your account added without errors (click the "test" button to see) -- congrats! Otherwise, we recommend you do the following, which has been previously tested and confirmed to work:
We recommend using an external database like this because it is more secure than directly exposing your production database to the internet.
If you have any questions about getting set up you can comment below or write us: email@example.com
Today, Zapier was caught in the snares of a widespread outage that affected dozens of large internet services who, like us, rely on Amazon Web Services to power their websites. It was widely reported on. For approximately 3 hours Zapier was at least partially inaccessible.
Starting at 10:36am PDT, our primary database started locking up as it appeared that it couldn't write to the underlying storage. Unfortunately, the precautions we took to ensure high availability by use of multiple availability zones also failed, meaning the database was inaccessible during this period.
To make matters worse, a few of our web and queue servers were also affected due to the underlying storage issues, as were some of our load balancers. While this didn't contribue to the original inaccessibility, it did complicate recovery procedures as we scrambled to replace broken servers with new ones.
In the end, very little data was lost in transition between services, as our system is designed to pick right back up where it left off. Webhook triggers in particular encountered widespread data loss for the period.
We're taking a few steps to ensure that this sort of issue is minimized in the future, these steps include:
We take downtime extremely seriously and it pains us to experience them. Do not hesitate to contact us at firstname.lastname@example.org with any questions or concerns.
Get new articles about productivity, company building, process delivered to your inbox once a week.