> For the complete documentation index, see [llms.txt](https://docs.flightwatching.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flightwatching.com/user-manual/designer-user-manual/edit-ifts/ift-v2/fw.webhook.md).

# FW\.webhook

await FW\.webhook(webhookId, payload, eventId)

If you have a web connector (see layouts), you can call it in `push` mode from an IFT thru this function. All the IFTs of this webhook will be trigged, as if an external process had. You will not need to specify an `api-key` as it is often mentionned, as we are working locally serverside

* `webhookId`: the ID of the webhook (a big uuid), the ref or the name of the webhook. In the below example, `webhookId` can either be `01eb566a-9eef-4773-ae4c-15971cded9fa` or `XLSX_FAULT2FIN`or `the plugin/component ref` Be careful when using the name of the layout as a user can change it and can be not unique!!! In that case, the behavior is not predictable!!
* `payload` \<optional> is an object that will be injected as the IFT variable. In the below example, the payload would be injected in a variable named `infos`
* eventId: \<optional> is the ID of the event the webhook will be run against (it will be injected into the [EVT](/user-manual/designer-user-manual/edit-ifts/ift-v2/fw.getevent.md) of the webhook). If not passed,  the IFT's EVT will be propagated.

{% hint style="info" %}
Webhooks are useful in this context to factorize code and reuse it in other IFTs (different layouts, etc...)
{% endhint %}

![](https://4203901285-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LucrvGdSn3RONbIcfqh%2F-McOoDbexbDkSwBjeL7x%2F-McOpRapp2MIxn1VDSS9%2Fimage.png?alt=media\&token=0b56c129-26ed-4ddf-8b50-ec03c348a3ce)
