Goal
Create a custom trigger type that fires functions in response to events iii doesn’t handle out of the box — for example incoming webhooks, file-system changes, or third-party service callbacks.Steps
1. Implement the trigger handler
A trigger handler is an object (Node) or class/trait (Python, Rust) with two callbacks:registerTrigger— called when a function binds to your trigger type. Set up whatever listener or subscription is needed.unregisterTrigger— called when the binding is removed. Tear down the listener.
TriggerConfig containing the trigger id, the bound function_id, and the caller-supplied config.
- Node / TypeScript
- Python
- Rust
webhook-trigger-type.ts
2. Register the trigger type
CallregisterTriggerType with an id, a description, and the handler from above. The id is the string other workers will reference when they call registerTrigger.
- Node / TypeScript
- Python
- Rust
webhook-trigger-type.ts
3. Bind functions to the custom trigger
From any worker — including one written in a different language — functions can now bind to thewebhook trigger type with registerTrigger. The config you pass in config is forwarded directly to your handler’s registerTrigger callback.
- Node / TypeScript
- Python
- Rust
github-webhook.ts
4. Unregister the trigger type
When the worker that owns the trigger type shuts down, callunregisterTriggerType to remove it from the engine. Any triggers still bound to the type will stop firing.
- Node / TypeScript
- Python
- Rust
teardown.ts
Result
Your customwebhook trigger type is registered with the engine. Any function in any worker can bind to it with registerTrigger({ type: 'webhook', ... }), and the engine routes registration and teardown calls to your handler. The same pattern works for any event source — file watchers, message brokers, hardware signals, or anything else you can subscribe to in code.
Before creating a custom type, check the built-in trigger types —
http, cron, queue, subscribe, state, and stream cover the most common event sources.