Trigger based SaaS integrations: webhooks vs Zapier

If you ask a developer today how to build a trigger-based SaaS integration (for example, with Salesforce or HubSpot), they'll likely recommend using Zapier.

However, I'd argue a webhook-based solution makes these integrations:

  • more native to your web app,
  • easier to configure for your users, and
  • more programmatically customizable

Webhook integrations 🔗

A ton of SaaS platforms (Salesforce, HubSpot, Asana, JIRA, Stripe, Quickbooks, Xero, etc.) support registering webhooks to be notified when data is updated. For example, you may want to receive a notification when:

  • an Asana task is completed, created, or commented on
  • a Salesforce opportunity, lead, or contact is created
  • a Quickbooks invoice is created or modified

Although most of these are possible to achieve with Zapier, using webhooks to do this makes the experience for users of a SaaS product much simpler. Rather than leaving your application to configure a new Zap, you could have the same functionality with one click.

Webhook integrations vs Zapier integrations 🤔

Let's compare the user experience of a webhook-based native integration with a Zapier powered integration, solely based on the steps the user has to take to link their Salesforce account.


As you can see, the webhook-based integration is a cleaner experience for users, that makes it easier to get started and minimizes points where they could drop off. From my personal experience of using both types of integrations, native webhook integrations are infinitely less frustrating to configure (plus, they don't cost your user anything).

Zapier is still useful 🧩

By no means should you stop using/supporting Zapier. Zapier enables non-technical users to stitch together many different applications ****to create powerful workflows.

For the developer of a SaaS app, that means building a Zapier integration gives your users access to a ton of awesome data sources and makes your platform work with them instantly. This is generally a great value add for users.

However, Zapier should not be the only route for users to integrate their apps. For platforms the bulk of your users integrate with, you should definitely offer a native flow that makes it easy for users to onboard and gives you more control over their experience.

How to build webhook integrations? 🛠️

Creating a webhook integration, on a high level, boils down to 3 steps:

Create an authorization flow 🔑

The first step is building an authorization flow so your users can login to the 3rd party app(s) to integrate with. This typically involves creating an OAuth app, redirecting users to a login page, and obtaining API access tokens.

A sample of an authorization flow with Quickbooks is shown below:


Sample Quickbooks OAuth authorization flow

Register a webhook endpoint 📒

The next step is to register a webhook endpoint in the 3rd party app. This process varies between SaaS apps – for example, HubSpot allows you to configure this as part of your OAuth app settings while Asana requires you to configure this via their API.


HubSpot OAuth App webhook settings

Create the webhook consumer 🔌

Finally, you must consume the incoming data from the 3rd party platform within your own app. This process is dependent on your web app and use case, but platforms like Hookdeck can make the development process much easier and solve many of the infrastructure issues for you.



Although Zapier is a great option for getting blanket coverage of many different data sources, the most widely used integrations should be built natively. This can vastly improve the user experience, prevent drop off, and give you more flexibility in how it's implemented – for trigger based integrations, webhooks are the obvious way to achieve that.

I'd love to get feedback on this from the IndieHackers community:

  • Have you dealt with trigger based integrations before? What was the use case? How did you handle it?

For those of you who have used Zapier in the past:

  • What were your experiences using Zapier? What'd you love about it? What'd you dislike?

For those of you who have used webhook-based integrations in the past:

  • How did you build your webhook consumers? Did you build it all internally? Did you automate registration of webhooks?

Thanks for reading! 👋

  1. 3

    If you ask a developer today how to build a trigger-based SaaS integration (for example, with Salesforce or HubSpot), they'll likely recommend using Zapier.

    What makes you say that? I think it's unlikely - extremely unlikely - that an actual developer would think of Zapier before using a webhook natively.

    1. 1

      I think typically SaaS products benefit from having a Zapier integration, so the general idea is that supporting Zapier first gives your users more value than a native webhook. I agree with you though – using webhooks natively gives more control and produces a better experience.

  2. 2

    Love it! Webhooks are no doubt a better experience for the end-user.

  3. 1

    I tend to agree with what you are saying. We just launched textgun.io for sending and receiving SMS text messages in Zapier. Zapier is very easy from an end user point of view, but their developer platform is a little user-hostile if i do say so my self. But we got there in the end. Anyone looking to add Zapier SMS to their automation workflow please feel free to reach out and do check out textgun.io

  4. 1

    100% agree with you here. Every SaaS platform should take the time to build out a native integration strategy, its a proven method to scaling your platform growth. Zapier does have its benefits but when you only offer Zapier integrations you are essentially asking your users to figure out the integrations part themselves. Not ideal.

    We built Pathfix (https://pathfix.com) to take care of the oauth and integration complexity. A lot of our customers are now able to quickly offer native integrations vs a Zapier

  5. 1

    Nice job @hsyyid!

    I definitely agree that native webhooks are the way to go. That is why we are building www.hostedhooks.com. We want to make it incredibly easy for platforms to offer a native webhook solution.

    Would love to get your feedback on what we've built!

    1. 2

      Definitely! Just checked out HostedHooks, found it very interesting (just watched your demo). I've seen platforms like Hookdeck that make receiving webhooks at scale easy, but I think HostedHooks is the first time I've seen a platform for the other side (sending webhooks reliably). Really excited to see where you take it!

Trending on Indie Hackers
I quit. 52 startups in 52 weeks 47 comments Launching new product today, hope to get your support and feedback ❤️ 11 comments Twitter accounts directory 11 comments What tech stack is everyone using? 4 comments How do you price a newsletter? 2 comments World's hardest problems Index 2 comments