Zaplify Webhooks allows you to subscribe to events happening in a Zaplify account. Rather than polling for new data regularly through making API calls, Zaplify can send an HTTP request to an endpoint you configure. You can configure subscribed events (webhooks) in Zaplify under the Webhooks page under settings. We recommend using Zapier or Make.com to set up your integration with Zaplify (more info below).
Webhook Events
When configuring webhooks you should create one webhook for each event you want to subscribe to. There are currently eight events available:
All events will be sent to the user-provided webhook url as a POST request with a JSON body payload with a size up to 1MB. The Content-Type of all data sent is “application/json”. The exact data structure for each webhook can be found when configuring the webhook in the application.
Overview
An overview of a CRM integration through webhooks.
Prospect Found Webhook
This might be the most important webhook in Zaplify. It is dispatched when a user finds or views a prospect for the first time in Zaplify and will contain basic identification and contact data for the prospect. We recommend you as an integrator to check this data against your CRM in as many ways as possible to confirm whether or not the prospect already exists in your CRM. We refer to this matching process as the “Prospect Matching Algorithm” (more info in the next section). If a prospect does exist in your CRM you can send back a POST request to Zaplify through the Prospect Sync endpoint (more information below) with this prospect’s corresponding id that you have in your CRM (for example contactId or leadId in SalesForce). When using the Prospect Found webhook together with the Prospect Sync endpoint Zaplify will know what prospects already exist in your CRM and show that to the user on the frontend, so that the user knows whether or not it exists in the CRM.
Prospect Sync Endpoint
The Prospect Sync endpoint is not a webhook, but rather an API endpoint that Zaplify exposes. This endpoint enables you to send the local id that identifies a prospect in your CRM back to Zaplify. It is highly recommended to use this endpoint together with the Prospect Found and Prospect Qualified webhooks. Doing so will allow a two-way
synchronization process in between Zaplify and your Integration. This will also simplify the implementation of all events occurring after a prospect has been Qualified in Zaplify.
POST https://api.zaplify.com/api/v1/apps/webhooks/prospects/associate {
“prospectId”: <Zaplify prospect ID>
“associatedId”: <Contact ID from CRM>
}
Prospect Qualified Webhook
The Prospect Qualified webhook is fired when a user purchases a prospect in Zaplify and will contain the prospect data of the purchased prospect. If you are using the Prospect Found webhook and Prospect Sync endpoint to let Zaplify know what prospects already exist in your CRM, the CRM ID of each contact/lead that you have sent back to Zaplify through the Prospect Sync endpoint will be included in the payload for each prospect sent through the the Prospect Qualified Webhook. The id will be a string value under the property field associatedIntegrationId. If the prospect was not found in your CRM when synchronizing the prospects, or if you choose to not use the Prospect Sync endpoint at all, the associatedIntegrationId property will be null.
When the associatedIntegrationId is null you can suggestively choose to create the contact/lead in your CRM and return the id from that newly created contact/lead to Zaplify through the same Prospect Sync endpoint. This will make Zaplify aware of the associatedIntegrationId for all purchased prospects, which will simplify the integration process for all other events.
Prospect Action Executed Webhook
The Prospect Action Executed webhook will be fired each time a Workflow Action (“touchpoint”) has finished successfully. The webhook will send a payload with basic prospect identification and contact data, the associatedIntegrationId (if the Prospect Sync endpoint has been used) and data about what action that was executed as well as metadata for the action such as the message or email content that was sent. You can use this data to update a lead/contact in your CRM with activities or notes for tracking purposes.
Prospect Finished Webhook
The Prospect Finished webhook will be fired each time a Prospect has finished successfully in one of your campaigns. The webhook will send a payload with basic prospect identification and contact data, the associatedIntegrationId (if the Prospect Sync endpoint has been used) and the campaignId as well as the campaign name.
Prospect Replied Webhook
The Prospect Replied webhook will be fired each time a Prospect has replied to one of your messages. The webhook will send a payload with basic prospect identification and contact data, the associatedIntegrationId (if the Prospect Sync endpoint has been used) and the campaignId as well as the campaign name.
Avoiding Duplicate Prospects
Avoiding duplicate prospects is in many cases the most essential part of your integration. The better and more comprehensive you as an integrator can make the prospect matching algorithm, the lower the risk for duplicates will be. In this section we have put together a few tips and tricks on how to design a matching algorithm. These are based on how we avoid duplicates in our native integrations.
Avoiding duplicates is all about finding the lead/contact in your CRM that corresponds to a prospect you have found through Zaplify, if it exists. In other words, all you need is one query to your CRM, where you map prospect details from the Zaplify prospect to the corresponding query parameters for your CRM. If that query returns a prospect or not will tell whether the prospect exists or not in your CRM. Note that matching the prospect’s company/account in most cases also is a part of this process.
Build your query
When building the query for finding a prospect in your CRM it is advisable to use several OR-cases where each case contains an AND-group of parameters with prospect data points sufficient to identify the prospect. For example the first name, last name and company name could be one query-group, first name, last name and company domain could be a second, and the email address alone would be a third. The 4 cases we have found most efficient for our native integrations are:
* Linkedin profile url
* First name, * Last name and * Company name
* First name, * Last name and Company domain
Email address
* indicates a guaranteed data point, meaning that all prospects found with a Zaplify Prospect Search have the datapoint.
Note: the Company domain and Email address do not exist for all prospects and therefore are not sufficient parameters to use alone in your matching algorithm.
💡Tip to increase your query robustness
Note that you might have to use two separate queries for the company/account matching and lead/contact matching.
Make sure that the query is non-case-sensitive.
Make sure to use as many available prospect identifier cases as possible.
Note that company names from Zaplify may differ slightly from the company names you have in your CRM. For example you might have “Alphabet Inc.” in your CRM, while Zaplify will give you just “Alphabet”.
An example logic chart over a simple matching algorithm
Building the integration
When preparations have been made and it is time to build the integration, there are many alternative tools available. The integration can be set up on a server, implemented through code by a developer, or on a no-code integration platform like Zapier, Integromat, Parabola.io, or Automate.io. They all provide drag-and-drop workflow builders, where integrators can work quickly and effortlessly, without having to worry about security, testability, maintainability, and extendability. Also, they provide great built-in monitoring tools that make bugs easy to find and fix, while building/maintaining the integrations can be done by any employee with some tech knowledge, eliminating the dependency on developers to set up integrations.
Which one should we choose?
Depending on your requirements, different providers can be better or more fitting. While building Zaplify we had the opportunity to try out a few. Here is our quick take on our two favorites: Make.com and Zapier.
Zapier
Zapier
Zapier is the most established tool of its kind, where high security, great compatibility, and a simple UI make the set-up process just a few hours long for almost any integration. The only downside with Zapier really is that it can become pricey if your integration has many steps. Each processed step in your Zap counts as a “Zapier Task”. You have a limited amount of “Zapier Tasks” every month. The amount depends on the pricing plan you choose.
Make.com (formerly "Integromat")
Make.com (formerly "Integromat")
Make.com is a cheaper solution and easier to handle in more complex integrations. Make's UI focuses on data flow, conditional logic and branching. Their greatest strength is providing a good overview and workflow control, even for huge integrations with dozens of steps. You get more “Tasks” (“Operations” in Make) per month than what you get with Zapier for the same price. Although Make.com has drawbacks when it comes to Enterprise-compatibility, and their UI might be harder to understand for less techy integrators.