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):

Param	Description
type	The event type (in dot notation).
timestamp	The original date/time of the event in YYYY-MM-DD HH:MM:SS TZ format.
data	Any specific data related to the event. For blockchain events, this will include the block and transaction objects.

Example payload

{
    "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.