Webhooks

Webhooks enables Speed to push real-time notifications to your app. You can then use these notifications to execute actions in your application.

You must register a webhook endpoint to receive live notifications about all subscribed events occurring in your Speed account. You can configure webhook endpoints via the APIs. However, most users configure webhooks from the web application, which provides a user interface for registering and testing your webhook endpoints.

Let's get an overview of webhooks and events before registering a webhook endpoint.

Overview

A Webhook is an HTTPS request triggered by an event happening in Speed and sent to your (destination) system, often with a payload of data. When an event occurs, Speed will send events objects directly to the endpoint you registered. Webhooks are automated, which means they are sent out automatically when an event occurs in the Speed system.

You should be able to use webhooks for the test as well as live mode. To receive real-time events from Speed, first, you must register your webhook endpoint. A webhook endpoint must have an URLand a list of enabled_events.

ℹ️ You will be able to add the same webhook endpoint URL multiple times.

But for this, you need to understand what events are in Speed and which ones you have to enable. Also, you need to understand the structure of how webhooks work and how Speed sends these event objects. For this, let's first understand the events below.

Understanding events

Events are our way of letting you know when something interesting happens in your account. When an event occurs, we create a new event object. If you registered a webhook endpoint, we send the enabled events to your endpoint as part of a POSTrequest. These events could be triggered/logged with a synchronous activity, like when you make a call or hit an API, or for an asynchronous activity, like a payment made by a customer.

How does webhooks work?

Let's say that you are done setting up a webhook endpoint using Speed APIs or web applications and ready to receive the events from Speed. Next, your customer pays you using other Speed features like a checkout session, checkout link, or payment link. You need to see if that link or session is paid. Well, this is where webhooks come in. An event called payment. paid is created, and this event is sent to you using the registered endpoint on which you have enabled this event. And once you receive this event as a post request on your HTTPS URL, all you have to do is verify the signature so that you know the webhook has been sent by Speed. Once verified, you must send a 2XX response to Speed.

This entire process must pan out to receive real-time updates about any event occurring in your speed account. For this to happen, let's see the steps you need to follow:

• Identify the events you want to monitor.
• Setup a webhook endpoint as an HTTP endpoint (URL) on your local server.
• Handle requests from Speed by parsing each event object and returning 2xx response status codes.
• Test that your webhook endpoint is working correctly.
• Deploy a publicly accessible HTTPS URL as your webhook endpoint and register it with Speed.

Use case it solves

Webhooks are particularly useful for asynchronous events like when a customer makes a payment or when you receive recurring payments. A webhook between Speed and your app tells your app whether the customer’s payment is successful or not. Use webhooks to get these real-time updates on your Speed account, so your integration can automatically trigger reactions.