Web Hook

Introductory learning about web hook with best practices.

1. Introduction

Webhooks are also known as reverse APIs or push APIs because they put the responsibility of communication on the server. Rather than the client sending HTTP requests and asking for data until the server responds, the dedicated application server sends the client a single HTTP POST request as soon as the data is available for use. Webhooks are not APIs, but they work together. An application must have API to use a webhook with events.

Webhooks are a way for applications to communicate automatically. This can either be public or private. Private means for that webhooks, only the owner of a specific system’s account can register. It is not accessible for anybody to track the account’s events.

2. Webhook Functioning

We can register a webhook by the URL to notify once given events occur. This Initial step is usually done via either a UI or API.

The created route holds the logic to be executed once the event occurs.

This system does not have to know the process of what needs to be executed, it only needs to keep track of the routes to notify.

Figure 1 Web Hook process

It is really useful since everything remains loosely coupled. System B, receiving the notification through the selected URL, not only knows an event occurred on another system but it can also able to react it.

The route containing the logic must be accessible through an HTTP POST request.

Specifically, a POST request is required in this case because it gives us the ability to include a body to the request. It is most of the time a simple JSON object, but it can also be an XML doc.

It is directly in the body structure that we will find the information discerning what kind of event happened. And it will tell us which user triggered it and when, and we will get able to know more event-specific information.

Event types

Our webhook endpoints should be configured to receive only the types of events required by your integration process. Listening to unnecessary events (or all events) will put undue strain on our server and is not recommended.

We can change the events a webhook endpoint will receive in the Dashboard or with the API.

We can view delivery attempts, event logs, and the retry logic when webhook events aren’t acknowledged.

View events

LISTENING WITH STRIPE CLI

We can use the Stripe CLI to listen for events directly in your terminal.

3. Real-time Webhook example

Let us explain on how a webhook works through a particular event with some shopping cart for developers, webhooks are used to notify other applications when that events occur in the cart, such as a new order.

This example shows the order.Completed event.

We are able to see the body, also frequently called the payload, of the event.

We have not created a server to run any actual logic right now. The purpose here is to understand how to process data info flows and how it gets triggered by events.

4. Best practices for using Webhooks

Webhooks provide an immensely powerful mechanism to track the state of transactions and take actions within our accounts. Review the below best practices to make sure our webhooks remain secure and function seamlessly with our process integration.

Quick Response

After receiving a webhook using an HTTPS endpoint process, it is very important to respond to that request with a 200 OK as quickly as possible.

A common pattern is to store the payload info in a message queue for later processing by a background worker process. This limits the chance of the request timing out/Expired and the webhook delivery counting as a failure.

Tracking failures

We can use delivery metrics to track all failed webhook deliveries and fix them before they affect merchants’ processes.

Recover Mechanism

If our app goes offline for an extended period of time, we can recover our webhook by registering again and able to be importing the missing data.

To register a webhook again, consult the application’s code to start registering the webhook. We can add a check that fetches all the available webhooks and registers only the ones that we need.

Import the missing data, we can fetch data from the outage period and fill it into your webhook processing code.

Handling Events

Handling webhook events correctly is very crucial to ensure our integration’s business logic works as expected.

Handle duplicates

As we know the webhooks API is designed to minimize duplicate webhook events, but it is still possible that we can receive the same event more than once. Our application should handle webhook events using idempotent operations, i.e., receiving the same webhook event a second time in a row should have no additional effect for processing. We can detect duplicate webhook events by looking for identical X-Shopify-Webhook-Id headers info, or by comparing the payload info directly to the previous state.

Manage delays

In some rare circumstances, we might experience delays in receiving webhooks. However, webhooks are always sent with the latest/recent data for the given resource. The payload of the delivered webhook should reflect the latest/recent properties for the resource between the time of the webhook's trigger and the webhook's eventual delivery.

If receiving webhooks up to a day late might cause issues in our application, then can compare the timestamp of the webhook to the current time.

Reconciliation jobs

Our app should not rely solely on receiving data from webhooks. Because webhook delivery is not always guaranteed, we should implement reconciliation jobs to periodically fetch data from the process.

Filter parameters

Most of the query endpoints support both the created_at_min and updated_at_min filter parameters. These filters can be used to build a job process that fetches all resources that have been created or updated since the last time the job ran.

Build scalable and reliable system

If we need to manage large volumes of event notifications to build a scalable, maintainable, and reliable system, then we can configure subscriptions to send webhooks to Amazon Event Bridge and Google Cloud Pub/Sub rather than through HTTPS.

5. Security

Endpoints security is critical to protecting our customers’ information. Stripe provides some ways for us to verify events are coming from Stripe in a secure way.

CSRF protection

If we are using Rails, Django, or another web framework, Our site might automatically check that every POST request holds a CSRF token. This is an important security function that helps protect us and our users from cross-site request forgery attempts. However, this security process might also prevent our site from processing legitimate events. If so, we might need to exempt the webhooks route from CSRF protection for the application.