Webhooks
Webhooks are specialized API endpoints designed to be triggered based on other events
Last updated
Was this helpful?
Webhooks are specialized API endpoints designed to be triggered based on other events
Last updated
Was this helpful?
Webhooks are API endpoints specifically designed for one system to automatically push information to another when a specific event happens. For example, Slack provides you with a webhook URL. This URL is ready and listening, much like your own API endpoint.
But here’s the key difference:
Something like a form submission endpoint receives data because the user initiated the request (e.g., they clicked 'Submit').
The Slack webhook receives data because your server, after processing the form (the event), initiated a new request, automatically pushing the form details to Slack's URL. Slack didn't ask for it; your system sent it because something happened.
You'd build webhooks in Xano typically to ingest information pushed from other places — like if a user pays for something via Stripe, or they perform an action in your app that you want to log.
You'll need to choose the encoding, or the format, of the data being sent to this endpoint. This will more often than not be JSON.
While Get All Raw Input offers flexibility, always check the documentation of the service sending the webhook. They will specify the structure (schema) of the data payload you should expect.
From here, the process is completely unique to whatever data is being sent to the webhook, and what you need to do with it.
Examples:
Store the data in a database table using Add Record
Transform or manipulate the data using Filters or an Expression
Send the data to another service, such as an analytics platform, using an External API Request
Begin a more in-depth process using a combination of the above to perform multiple actions, such as transforming data, storing it, and sending Emails
Just like any other API endpoint you're building, it's important to ensure that they are built securely. Webhooks have some more specific-to-them ways that they are usually kept locked up.
The service you're accepting requests from may offer signature verification. At a high level, this means that you would cross-check the signature they sent with your own calculated signature, using a private key that only you and the service are aware of, and ensure that they match.
If they match: The request is verified and you can proceed.
If they don't match: you should deny the request
In general, this process follows a typical flow:
Extract the signature provided in the request headers
Ensure you have a raw, unaltered copy of the request body (which you do using Get All Raw Input)
Similar to how standard User Authentication & User Data works, some services may just send an API key or bearer token as part of the request header. You'll want to compare this against your own stored key and ensure that they match.
It's also good practice to rotate this token on a regular basis to ensure that it is not compromised.
Use Middleware or Custom Functions to build your webhook verification and quickly deploy it across multiple function stacks.
Choose Custom API Endpoint and fill in the details. Make sure to select POST as the verb.
Typically, webhooks need to be able to dynamically process data that might look a little different between requests. So, we use to make sure that we aren't confined to just the inputs that are defined in the inputs section.
If the webhook is receiving a list of items, loop against them using
Use the proper Security filter (such as ) to encode your own signature, and ensure that it matches with the one you extracted from the request.
