On [Cloud plans and Self-Hosted & Enterprise Edition](/pricing), you can [connect workspace to Slack](../../integrations/slack.mdx) and enable an automated error handler on a given channel.

4. [Integrate it to Windmill](../../integrations/microsoft-azure-blob.md) by filling the [resource type details](https://hub.windmill.dev/resource_types/137) for Azure Blob APIs.

Once you've created an [S3 or Azure Blob resource](../../integrations/s3.md) in Windmill, go to the workspace settings > S3 Storage. Select the resource and click Save.

:::info

Windmill's integration with S3 and Azure Blob Storage works exactly the same and the features described below works in both cases. The only difference is that you need to select an `azure_blob` resource when setting up the S3 storage in the Workspace settings.

:::

S3 files in Windmill are just pointers to the S3 object using its key. As such, they are represented by a simple JSON:

<div className="grid grid-cols-2 gap-6 mb-4">

<DocCard

title="Persistent Storage - S3 Integration"

/>

</div>

:::info

:::

<div className="grid grid-cols-2 gap-6 mb-4">

<DocCard

title="Persistent Storage - S3 Integration"

/>

</div>

:::

Each Script and Flow created in Windmill gets autogenerated webhooks. The webhooks depend on how they are triggered, and what their return values are.


hiding potentially sensitive information and always corresponding to that

version of the script, even with overwrites.

Jobs can be triggered in asynchronous mode, meaning that the webhook is triggered, and the returning value is the uuid of the job assigned to execute the underlying code

These links are available in the "UUID/Async" tab.

The second type of autogenerated endpoint is the **synchronous** webhook. This

webhook triggers the execution, automatically extracts the underlying code's

:::

It's always better to use asynchronous mode as it allows your client not to wait for the response and it avoids Windmill to have to maintain a connection to your client while the job is running. However, for short-running jobs where it's easier in your code to block until you get a response, then use the synchronous mode.

When using the **synchronous mode**, the webhook returns the result of the script directly. If the script returns an error, the endpoint still returns the `200` status code with the error as a JSON object.

When using the **asynchronous mode**, the webhook returns a `uuid` and you can poll the [get job](https://app.windmill.dev/openapi.html#/operations/getJob) API call to fetch the status and results once it is completed.

To interact with Windmill you always need to use `Bearer` token authentication.


Webhook specific tokens allow sharing tokens publicly without fear since the token will only be able to trigger a specific script/flow and not impersonate you for any other operations.

It also avoids the hassle of having to create an anonymous user and check their permissions. If you can run the script yourself, then the webhook specific token will still inherit your own permissions.


Once you have a webhook URL and a user token, issue a request to the

endpoint and you will get the appropriate return as response.

Examples using cURL for `POST` requests:

curl -X POST \

--data '{}' \

-H "Content-Type: application/json" \

curl -X POST \

--data '{}' \

-H "Content-Type: application/json" \

Examples using cURL for synchronous GET requests:

curl -X GET \

-H "Content-Type: application/json" \

-H "Authorization: Bearer supersecret" \


It is possible for jobs to take request headers as arguments. To do so, either specify in the query args the headers to process at `include_header`, separated with `,`. e.g: `/api/w/admins/jobs/run_wait_result/p/u/user/undisputed_script?include_header=X-Sign,foo`

or use the env variable: `INCLUDE_HEADERS` with the same format so that all requests to any job will include the headers.

If the payload is not an object, it will be wrapped in an object with the key `body` and the value will be the payload/body itself. e.g:

print(body)

Similarly to request headers, if the query args contain `raw=true`, then an additional argument will be added: `raw_string` which contains the entire json payload as a string (without any parsing). This is useful to verify the signature of the payload for example (discord require the endpoints to verify the signature for instance).

For all sync run jobs endpoints, if the response contains a key `windmill_status_code` with a number value, that value will be used as the status code. For example, if a script or flow returns:

Note that if the status code is invalid (w.r.t [RFC9110](https://httpwg.org/specs/rfc9110.html#overview.of.status.codes)), the endpoint will return an error.

Similarly to the above, for all sync run jobs endpoints, if the response contains a key `windmill_content_type`, the associated value will be used as the content type header of the response. For example, if a script or flow returns:

with the response header: "Content-Type: text/csv".

It is possible to define a node at which the flow will return at for sync endpoints. The rest of the flow will continue asynchronously.

/>

</div>

Single port proxy can be leveraged to expose a webhook with a custom URL. In its docker-compose, Windmill uses Caddy but the logic can be adapted for others.

<!-- Resources -->

[runs]: ../5_monitor_past_and_future_runs/index.mdx