Menu
MUST use when configuring triggers.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
| name | triggers |
| description | MUST use when configuring triggers. |
Triggers allow external events to invoke your scripts and flows.
Trigger configuration files use the pattern: {path}.{trigger_type}_trigger.yaml
Examples:
u/user/webhook.http_trigger.yamlf/data/kafka_consumer.kafka_trigger.yamlf/sync/postgres_cdc.postgres_trigger.yamlf/inbound/orders.email_trigger.yamlAn email trigger routes incoming emails to a script or flow. Each trigger reserves a local-part: emails sent to <local_part>@<windmill_email_domain> are delivered to the configured runnable. Set workspaced_local_part: true to namespace it per workspace (the actual recipient becomes <workspace_id>-<local_part>@…); on Windmill Cloud this is required.
Senders may append URL-style extras to the local-part with +: mytrigger+foo=bar+baz=qux@…. They flow through to the script as email_extra_args (see below).
The runnable receives:
parsed_email — { headers, text_body, html_body, attachments[] }. Each attachment has { headers, body }.raw_email — the raw RFC 822 message as a string, or an S3 object ({ s3: "windmill_emails/<job_id>/raw.eml" }) if the message exceeds 1 MiB.email_extra_args (optional, only when sender appended +key=value extras) — a flat object of the parsed extras.With a preprocessor, all of the above are nested under event along with event.kind = "email" and event.trigger_path (the trigger's path). Without a preprocessor, trigger_path is not exposed — add a preprocessor if you need it.
Binary attachments are uploaded to the workspace S3 bucket and surface in parsed_email.attachments[i].body as:
{ "s3": "windmill_emails/<job_id>/attachments/<filename>" }
To read the bytes inside a script, use the wmill SDK:
// TypeScript
import * as wmill from "windmill-client"
const file = await wmill.loadS3File(parsed_email.attachments[0].body)
# Python
import wmill
data = wmill.load_s3_file(parsed_email["attachments"][0]["body"])
If the workspace has no S3 resource configured (Workspace Settings → Object storage), body falls back to the string "configure s3 in the workspace settings to handle attachments". The same applies to large raw_email bodies. Email attachment storage requires the server to be built with the parquet feature.
Text/HTML/inline parts are placed inline in body as strings.
Deploying local changes to the workspace can be destructive to remote state — only suggest/run a deploy when the user explicitly asks to deploy/publish/push, not when they say "run", "try", or "test". Deploy via git push or wmill sync push depending on how the repo is wired (see the Deploying section in AGENTS.wmill.md). sync pull is safe to run yourself — it never mutates remote state, though it does overwrite local files to match the remote (use sync pull --dry-run to only preview).
# Push trigger configuration — only when the user explicitly asks to deploy
wmill sync push
# Pull triggers from Windmill
wmill sync pull
MUST use when using the CLI, including debugging job failures and inspecting run history via `wmill job`.
MUST use when creating flows.
How to safely update SQLx offline query cache. MUST use when SQL queries change.
MUST use when writing TypeScript scripts. Bun is the default and preferred TypeScript runtime — pick it for TypeScript unless the script specifically needs Deno.
MUST use when writing Bun Native scripts. The script must start with //native to run on the native worker.
Use ONLY when a TypeScript script specifically requires the Deno runtime (Deno stdlib or deno.land URL imports). For all other TypeScript, use write-script-bun instead.
Based on SOC occupation classification
