Webhook vs. API—what's the difference? As you become familiar with SendGrid's services, or even those of many Internet companies, you'll see the term "API" used a lot. Increasingly, you may also see someone mention a "webhook."
At SendGrid, we've consciously made a distinction between the two in our documentation and any time we write or speak about our seven services for simplifying email. Here's how we break down the differences between webhooks and APIs.
API stands for Application Programming Interface, but what does that really mean? Rather than what it is, I find it easier to talk about what APIs enable. APIs can share data or functionality. For example, you might use a places API to look up restaurants by location or name, pulling out a lot of data about each place. Then you might combine that with a mapping API, using it as an interface for displaying your data.
Programmers who make a request to an API will then receive a response. For example, using our Web API to send an email, you'd pass the email contents with the request. If all goes well, you will receive a response declaring success.
Sometimes people call webhooks reverse APIs, but perhaps more accurately a webhook lets you skip a step. With most APIs there's a request followed by a response. No request is required for a webhook, it just sends the data when it's available.
To use a webhook, you register a URL with the company providing the service. That URL is a place within your application that will accept the data and do something with it. In some cases, you can tell the provider the situations when you'd like to receive data. Whenever there's something new, the webhook will send it to your URL.
Baseball managers could really use webhooks. As the game progresses, they often want to change pitchers. To do this requires the new pitcher to first warm up in the bullpen, which is usually over 300 feet from the team's dugout. If you watch baseball on television, you'll often see the manager pick up a phone in the dugout. He's making a call to the bullpen to check on the new pitcher.
"Is he warmed up yet?"
"Not yet"
Then he hangs up the phone. In a few minutes, he'll have to call again. Programmers would call this polling and it's process-intensive for both sides. A webhook lets you say, "call me when he's warmed up."
SendGrid has two distinct webhooks related to each direction that email flows:
Event Webhook provides data about the emails you send, such as bounces and when the recipient clicks a link.
Inbound Parse Webhook allows your application to receive email as soon as a message comes in.
Some non-SendGrid webhooks:
Twilio's webhooks send text messages and voice calls to your application.
DropBox just announced webhooks to provide real-time notifications about file changes in Dropbox.
Metwit added webhooks to its weather API to provide notifications when specific types of weather occur in a particular location. It inspired my post on why every API needs webhooks.
Now, you know all the differences between a webhook vs API.
Now it's time to start doing something with those webhooks. Here are four things you can do with webhooks, including testing them on your local machine or connecting them to other services.
