Webhook

What is a Webhook?

Webhook (Advanced-Topic) – Use webhooks to send data to an external system. Funnel Webhooks are triggered when a new contact is created or updated and when a new purchase is created or updated.

There are two ways your apps can communicate with each other to share information: polling and webhooks. As one of our customer champion’s friends has explained it: Polling is like knocking on your friend’s door and asking if they have any sugar. Webhooks are like someone tossing a bag of sugar at your house whenever they buy some.

Webhooks are automated messages sent from apps when something happens. They have a message—or payload—and are sent to a unique URL—essentially the app’s phone number or address.

They’re much like SMS notifications. Say your bank sends you an SMS when you make a new purchase. You already told the bank your phone number, so they knew where to send the message. They type out “You just spent $10 at New Store” and send it to your phone number +1-234-567-8900. Something happened at your bank, and you got a message about it. All is well.

Webhooks work the same way.

Take another look at our example message about a new order.

Bob opened your store’s website, added $10 of paper to his shopping cart, and checked out. Boom, something happened, and the app needs to tell you. Time for the webhook.

Wait: who’s the app going to call? For webhooks, you first need to tell the first app—your eCommerce store, in this case—the webhook URL of the app that needs the data.

Say you want to make an invoice for this new order. You’d first open your invoice app, make an invoice template, and copy its webhook URL—something like yourapp.com/data/12345. Then open your eCommerce store app, and add that URL to its webhook settings. That URL is your app’s phone number, essentially. If another app pings that URL (or if you enter the URL in your browser’s address bar), the app will notice.

Ok. Back to the order. Your eCommerce store got the order and knows it needs to send the details to yourapp.com/data/12345. It then writes the order in a serialization format. The simplest is form-encoded, and your customer’s order would look something like this:

Customer=bob value=10.00&item=paper

Now you need to send the message. The simplest way to send data to a webhook URL is with an HTTP GET request. Literally, that means to add the data to the URL and ping the URL (or enter it in your browser’s address bar). The same way you can open Zapier’s about page by typing /about after zapier.com, your apps can send messages to each other by tagging extra text with a question mark on the end of a website address. Here’s the full GET request for our order:

https://yourapp.com/data/12345?Customer=bob&value=10.00&item=paper

Deep inside your invoice app, something dings and says “You’ve got mail!” and the app gets to work, making a new invoice for Bob’s $10 paper order. That’s webhooks in action.

Remember when you had to check your email to see if you had new messages—and how freeing push email was? That’s what webhooks are for your apps. They don’t have to check for new info anymore. Instead, when something happens, they can push the data to each other and not waste their time checking and waiting.

That’s the simple version. Technically, webhooks are “user-defined callbacks made with HTTP” according toJeff Lindsay, one of the first people to conceptualize webhooks. Webhooks are data and executable commands sent from one app to another over HTTP instead of through the command line in your computer, formatted in XML, JSON, or form-encoded serialization. They’re called webhooks since their software hooks—or functions that run when something happens—that work over the web. And they’re typically secured through obscurity—each user of an application gets a unique, random URL to send webhook data to—though they can optionally be secured with a key or signature.

Webhooks typically are used to connect two different applications. When an event happens on the trigger application, it serializes data about that event and sends it to a webhook URL from the action application—the one you want to do something based on the data from the first application. The action application can then send a callback message, often with an HTTP status code like 302 to let the trigger application know if the data was received successfully or 404 if not.

Webhooks are like APIs—but simpler. An API is a full language for an app with functions or calls to add, edit, and retrieve data. The difference is, with an API, you must do the work yourself. If you build an application that connects to another with an API, your application will need to have ways to ask the other app for new data when it needs it. Webhooks, on the other hand, are for one specific part of an app, and they’re automated. You might have a webhook just for new contacts—and whenever a new contact is added, the application will push the data to the other application’s webhooks URL automatically. It’s a simple, one-to-one connection that runs automatically.

Conclusion

Is your company in need of help? MV3 Marketing Agency has numerous Marketing experts ready to assist you. Contact MV3 Marketing to jump-start your business.

 

« Back to Glossary Index