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.
Here's a quick rundown.
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:
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.
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.
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.
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.
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:
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.
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!