Whether it's your own app you're integrating or your intending to make a custom integration for someone else app, the action will happen on the Zapier's Developer Platform. And this guide will introduce you to it.
- Private vs. public apps
- The key concepts of a Zapier integration
- Searches vs Creates
- Best practices for your app's API
- The web builder vs. the CLI builder
- How to get your app in Zapier's public directory
In short, Zapier is a platform that allows you to connect two or more apps through APIs - short for Application Programming Interface. It's how apps talk to each other - a shared language if you will. And Zapier is what mediates between the two of them.
Using the Zapier Developer Platform you can:
- Connect Zapier to your app's API. Zapier handles the security and authentication aspects of this process.
- create and publish your integration following Zapier's guidelines and features. You'll be able to configure all the trigger, search and action steps you want.
- Make the finished integration available as a private, invite-only app, or request it go live in Zapier's public app directory
There's a lot more nitty-gritty tucked away in there (which we'll get into) but that's essentially what Zapier's platform is built for.
Private vs. public apps
We just talked about finishing your Zapier integration and sharing it with your users. For the majority of developers, this is how you're going to want to finish your build. But what if you want to skip the sharing part?
Luckily, Zapier has an option for that. It offers both public app integrations and private (a.k.a. invite-only) integrations. These private integrations are only available to the person who creates them and the people they decide to share them with. You'll get a unique invite you can use to give other Zapier accounts access to your integration.
This won't change too much on the pre-release side of things, but it's something to consider if you want to keep your app's Zapier integration to yourself or within your team.
An important note - if you're connecting an app to Zapier, for which you're not the owner or developer, or if you've not been hired by them directly, you will not be able to get your integration published in the public directory and can only use it in private/invite-only mode.
While you can still share these integrations publicly via your own website, it's important to note that Zapier prohibits any form of pay-for-access.
The key concepts of a Zapier integration
Anyone that's ever interacted with an API should be familiar with authentication. Authentication is used as an identifier to connect someone's account with App #1 to their account on App #2. In some cases, authentication might be even more limited than this (you need specific permissions to obtain authentication) but the general premise is the same.
Authentication is core to Zapier and can be done through an API key or OAuth 2.0 integration.
Triggers are another key, high-level concept in Zapier. If you've ever created a Zap, you'll know that one of the first steps is deciding what is going to trigger your Zap to run.
In non-Zapier terms, your "trigger" is the event that causes a Zapier process to run. For instance, your trigger may be receiving an email that contains the keyword "Spam", which causes the "Spam Filter" Zap to delete that spam email.
Once a trigger has activated your Zap, the next thing your Zap is going to do is perform an action. Actions are the counterpart to triggers, in that they're what your Zap actually does. In the Spam Filter example above, "deleting spam emails" would be your action.
Searches vs Creates
Actions come in two flavours: Searches and Creates. Creates are more popular thanks to being easier to understand and easier to implement successfully. As the name implies, a Create action is any action that creates something. This might be a new row in a spreadsheet, a text message, or an online certificate.
Searches are a bit more complicated, though still true to their name. A Search is any action that searches for specific data within a set. This might be looking for a keyword in the subject of an email, checking the heading of a paper, or finding a name among a list of contacts.
This can help you avoid duplicate data, for example, or string certain information from one app to the next, to use in a subsequent step.
Best practices for your app's API
Zapier has a great list of best practices for your API, and these can go a long way in making your Zapier integration a hit with users. Here’s more or less what’s covered:
- Use webhooks. Zapier polls for new data every ten to fifteen minutes — but that might not be often enough depending on what your app offers. To counteract this, you can use real-time webhooks; increasing the accuracy and efficacy of your Zapier integration.
- Document your API. Every developer knows the pain of working with a poorly documented service. Don't be that developer! Make sure your users understand how your integration works and how to set it up.
- Deprecate your API gracefully. Another nightmare for developers is axing an old bit of code and replacing it with something new. With a tool as heavily integrated as a Zapier API, this is inevitable. To make the process somewhat seamless, check out this article.
The web builder vs. the CLI builder
Zapier's Developer Platform comes in two varieties, the web builder and the CLI builder. As you can probably determine for yourself, the web builder is a web-based, visual integration builder, while the CLI builder is a more traditional, nuts and bolts way to build your integration.
One isn't necessarily better than the other, it just comes down to personal preference.
The web-builder is a smoother ride, especially for less experienced developers, but you may have fewer options. The CLI builder, on the other hand, allows you to work in your preferred development environment, but will require a steeper learning curve.
How to get your app in Zapier's public directory
After you've built your Zapier integration (and assuming you don't want to keep it private), the next and final step is publishing your integration to Zapier's public directory.
Before you do that, though, you'll want to create private instances of your integration for every possible use of your integration. This means creating a Zap for every trigger and action you've added to your service. This serves as a simple model of beta testing, before you go public.
Once you've done that, read through Zapier's Integration Development Guide to make sure you're not missing any rules or guidelines prescribed by Zapier. You should also read Zapier's App Guidelines to get an idea of how Zapier’s going to review your integration.
After that, it's just a matter of submitting and waiting.
Zapier will decide whether or not to approve your integration. If approved, it'll go live with a dedicated page in Zapier's public directory. Nice work!