# Webhooks

*Not to be confused with an inbound webhook attached to a webhook trigger, we also support sending (outbound) webhooks when events occur within your Wundaflow account.*

By consuming webhooks, your Web 2.0 application can react in near real-time to events on the blockchain. Using logic triggers, watching for events as granular as  from a specific wallet or to a specific contract method become trivial.

As webhooks are sent using resilient workflows, even if your application is down or network congestion prevents the webhook being acknowledged, you can be sure that you will never miss a notification. Automated retries and API polling as backup mean events are never lost or duplicated.

You can configure your webhook URL from within the Wundaflow console.

### Event properties

Webhooks are delivered as JSON POST requests and adhere to the Standard Webhooks schema (see standardwebhooks.com):

<table><thead><tr><th width="247">Param</th><th>Description</th></tr></thead><tbody><tr><td><code>type</code></td><td>The event type (in dot notation).</td></tr><tr><td><code>timestamp</code></td><td>The original date/time of the event in <code>YYYY-MM-DD HH:MM:SS TZ</code> format.</td></tr><tr><td><code>data</code></td><td>Any specific data related to the event. For blockchain events, this will include the <code>block</code> and <code>transaction</code> objects.</td></tr></tbody></table>

#### Example payload

```json5
{
    "type": "workflow.started",
    "timestamp": "2023-04-10 14:31:05 UTC",
    "data": {
        "id": "flow_4eC39HqLyjWDarjtT1zdp7dc",
        "workflow_name": "send-notification-email",
        "workflow_version": "latest"
    }
}
```

### Webhook headers

In addition to the payload (body) of the webhook, we also send 3 important headers along with the request:

* `webhook-id`: the unique webhook identifier.
* `webhook-timestamp`: integer unix timestamp of the webhook attempt (seconds since epoch).
* `webhook-signature`: the signature(s) of this webhook

We sign all webhooks so that you can be confident that the event did indeed originate from Wundaflow. You should never trigger any logic related to a webhook without first completing verification of the signature.

### Idempotency ID's

In a similar way that we support idempotency on API calls to avoid duplicate processing, the `webhook-id` can be used in the same manner.

Our webhook system promises **at-least-once delivery**, but this can mean that under certain network or system conditions you may receive multiple requests. For example, an error within your webhook receiver may mean that a request was received and queued, but a non-200 HTTP response was returned. Wundaflow will consider this request failed and retry.

In this and similar circumstances, you can rely on the `webhook-id` to decide if processing has already taken place or not.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.wundaflow.com/core-concepts/webhooks.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.