Preprocessors

Preprocessors transform incoming requests before they reach the runnable. They’re triggered exclusively through webhooks, HTTP routes, email triggers, WebSocket triggers, Kafka triggers, NATS triggers, Postgres triggers, SQS triggers, or MQTT triggers — not through UI invocations.

This separation enables you to handle argument preprocessing differently depending on trigger type while keeping a simple schema form in the UI.

How preprocessors work

The preprocessor function receives an event parameter containing trigger data plus metadata. The event always includes a kind field identifying the trigger type, with additional fields specific to each trigger.

Preprocessors support only TypeScript (Bun/Deno) and Python.

Script preprocessor

In scripts, export an additional preprocessor function alongside main(). The returned object’s keys must match the parameter names in main().

For example, returning { b: 1, a: 2 } calls main(2, 1) for main(a: number, b: number).

The editor provides a test tab in the right panel for validating preprocessor logic against sample requests.

Supported event types

• webhook: body, raw_string, query, headers
• http: trigger_path, body, raw_string, route, path, method, params, query, headers
• email: trigger_path, parsed_email, raw_email
• websocket: trigger_path, msg, url
• kafka: trigger_path, payload, brokers, topic, group_id, partition, offset
• nats: trigger_path, payload, servers, subject, headers, status, description, length
• sqs: trigger_path, msg, queue_url, message_id, receipt_handle, attributes, message_attributes
• mqtt: trigger_path, payload, topic, retain, pkid, qos, v5 properties
• gcp: trigger_path, payload, message_id, subscription, ordering_key, attributes, delivery_type, headers, publish_time

Flow preprocessor

For flows, create a preprocessor step by clicking the plus button above the Input step. The returned object determines parameter values passed to the flow inputs.

Flow preprocessors support an additional event type:

• postgres: trigger_path, transaction_type, schema_name, table_name, old_row, row

The same logic applies: return keys must match flow input names exactly.