triggers

Create a file named path.http_trigger.yaml with required fields script_path, is_flow, route_path, request_type, authentication_method, http_method, is_static_website, workspaced_route, wrap_body, and raw_string. The route_path must not start with a slash.

Define a *.kafka_trigger.yaml file with kafka_resource_path, group_id, topics, and filters as required fields. You can also set auto_offset_reset to latest or earliest and disable auto_commit to commit offsets manually.

Trigger files follow the pattern {path}.{trigger_type}_trigger.yaml, such as u/user/webhook.http_trigger.yaml or f/data/kafka_consumer.kafka_trigger.yaml. Supported types include http, websocket, kafka, nats, postgres, mqtt, amqp, sqs, and email.

Binary attachments are uploaded to the workspace S3 bucket and appear as { s3: path } objects in parsed_email.attachments. Read them with wmill.loadS3File in TypeScript or wmill.load_s3_file in Python; without S3 configured, the body falls back to a placeholder string.

No, wmill sync push deploys local changes and can destructively modify remote state, so only run it when explicitly asked to deploy. Use wmill sync pull or sync pull --dry-run for safe operations that never mutate remote state.

Yes, the *.postgres_trigger.yaml schema supports logical replication CDC through required postgres_resource_path, publication_name, and replication_slot_name fields. It subscribes to a PostgreSQL publication and invokes the configured script or flow on changes.