# Webhooks

[Webhooks](https://en.wikipedia.org/wiki/Webhook) are HTTP requests sent to your server from SignalWire when an event occurs. They help receive information about events like inbound calls to your phone numbers, or messages.

In addition to getting information about events, some webhooks also allow you to tell SignalWire how an event should be handled.

During development, you can use localhost tunneling applications like [ngrok](https://ngrok.com/) to test your webhook handlers locally. See [the ngrok quickstart guide](https://ngrok.com/docs/getting-started) to get started.

## Configure webhooks for phone numbers

To handle an inbound call or message, you point your phone number at a [Resource](/content/docs/platform/resources/index.html) that holds your webhook URL. When an event arrives, SignalWire requests that URL and your server responds with [SWML](/content/docs/swml/index.html), the SignalWire Markup Language that tells SignalWire how to handle the call.

200 OK, SWML

Incoming message

SignalWire

Webhook HTTP request to your server

Your webhook handler

Generate SWML to reply to the message

##### What's a Resource?

[Resources](/content/docs/platform/resources/index.html) are the building blocks of SignalWire applications. They include AI Agents, SWML Scripts, cXML Scripts, SIP Endpoints, and more.

### Create a Resource for your webhook URL

In the SignalWire Dashboard, open the **My Resources** tab and click **\+ Add**, then choose **SWML Script**.

The Resource selection menu

Give the script a name, set **Handle Calls Using** to **External URL**, and enter your webhook URL in the **Primary Script URL** field. Click **Create** to save the Resource.

### Assign the Resource to your phone number

Open the **Phone Numbers** tab and select the number you want to configure.

Click **Edit Settings**. Under **Inbound Call Settings** (or **Inbound Message Settings** for messaging), choose **Assign Resource**, select the Resource you created, and click **Save**.

## Status callbacks to keep track of events

Status callbacks are asynchronous HTTP requests SignalWire sends to your server as a call, message, or recording moves through its lifecycle, keeping your application informed of each state change.

You subscribe to a status callback **programmatically**: when you create the call or message, provide a callback URL on the relevant SWML method, and SignalWire posts to it each time the state changes. What you set and the states you receive depend on what you’re tracking:

| To track | Provide a callback URL on | States you’ll receive |
| --- | --- | --- |
| **Voice calls** | `call_state_url` on [`connect`](/content/docs/swml/reference/calling/connect/index.html) | `created`, `ringing`, `answered`, `ended` |
| **Messages** | `status_callback` on [`send_sms`](/content/docs/swml/reference/calling/send-sms/index.html), or `status_url` on [`reply`](/content/docs/swml/reference/messaging/reply/index.html) | `queued`, `initiated`, `sent`, `delivered`, `undelivered`, `failed`, `read` |
| **Recordings** | `status_url` on [`record_call`](/content/docs/swml/reference/calling/record-call/index.html) | `recording`, `paused`, `finished`, `no_input`, `error` |

For voice calls, `call_state_events` defaults to `['ended']` — set it explicitly to also receive `created`, `ringing`, and `answered`.

Status callbacks are best-effort notifications, not a reliable realtime signal. They are delivered asynchronously over HTTP, so a callback can arrive late, arrive after a retry, or not arrive at all — if your server is unreachable when SignalWire sends the request, the callback is simply lost, and nothing notifies your application that it was missed.

For critical paths, use a mechanism whose failure modes are visible to your application:

- **[RELAY over WebSocket](/content/docs/server-sdks/reference/python/relay/index.html)** — events arrive over a persistent connection, so your client knows immediately when it is disconnected and can fail safe.
- **In-call flow logic** — act on results inside the call flow instead of out-of-band. SWML’s [`connect`](/content/docs/swml/reference/calling/connect#variables/index.html) sets result variables (`connect_result`) you can branch on.

## Verify webhook signature

To verify webhooks that originated from SignalWire, SignalWire signs its requests with a digital HMAC security key. You can verify that the security key matches the key documented in your Dashboard’s [API Credentials](https://my.signalwire.com/?page=credentials) with the `validateRequest` method.

For production applications, it is extremely important to verify the webhook signature to ensure the requests are coming from SignalWire and not a malicious third party.

```javascript
import { validateRequest } from "@signalwire/js";

// prepare raw body for validation
app.use(express.json({
  verify: (req: any, _res, buf) => {
    req.rawBody = buf.toString();
  }
}));

app.post("/mywebhook", (req: any, res) => {
  const valid = validateRequest(
    "<SIGNING_KEY_FROM_Dashboard>",
    req.headers["x-signalwire-signature"] as string,
    "https://example.ngrok.io/mywebhook", //this should be the public-facing URL of your webhook handler
    req.rawBody
  );

if (!valid) return res.status(401).send("Invalid signature");

res.sendStatus(200);
});
```