Documentation Index
Fetch the complete documentation index at: https://iii.dev/docs/llms.txt
Use this file to discover all available pages before exploring further.
What “writing a trigger” means
Workers don’t only call functions; they can also source events. When a worker advertises a
trigger type (e.g. http, cron, state, or a webhook you implement), any other worker can bind
its functions to that type via worker.registerTrigger({ type, config, function_id }). The engine
delivers each event to the bound function and routes the result back.
This page is about authoring new trigger types from inside your worker. For invoking functions and
binding triggers to functions from the consumer side, see Using iii / Triggers.
Declare a trigger type
Inside the worker, register the trigger type once during startup. The declaration names the type
and describes the shape of the config block consumers will pass to registerTrigger.
Node / TypeScript
Python
Rust
import { registerWorker } from "iii-sdk";
const worker = registerWorker(process.env.III_URL);
worker.registerTriggerType({
type: "webhook",
config_schema: {
type: "object",
properties: {
path: { type: "string" },
secret: { type: "string" },
},
required: ["path"],
},
});
import os
from iii import register_worker, InitOptions
worker = register_worker(
os.environ.get("III_URL"),
InitOptions(worker_name="webhook-worker"),
)
worker.register_trigger_type({
"type": "webhook",
"config_schema": {
"type": "object",
"properties": {
"path": {"type": "string"},
"secret": {"type": "string"},
},
"required": ["path"],
},
})
use iii_sdk::{InitOptions, RegisterTriggerType, register_worker};
use serde_json::json;
let url = std::env::var("III_URL").expect("III_URL must be set");
let worker = register_worker(&url, InitOptions::default());
worker.register_trigger_type(RegisterTriggerType {
trigger_type: "webhook".into(),
config_schema: json!({
"type": "object",
"properties": {
"path": { "type": "string" },
"secret": { "type": "string" },
},
"required": ["path"],
}),
})?;
Fire the trigger
When the underlying event source has something to deliver (an incoming HTTP request, a cron tick,
a state change, a webhook hit), the worker fires the trigger. The engine routes the call to every
function bound to that trigger.
Node / TypeScript
Python
Rust
import { registerWorker } from "iii-sdk";
const worker = registerWorker(process.env.III_URL);
await worker.fireTrigger({
type: "webhook",
payload: { path: "/incoming", body: requestBody },
});
import os
from iii import register_worker, InitOptions
worker = register_worker(
os.environ.get("III_URL"),
InitOptions(worker_name="webhook-worker"),
)
worker.fire_trigger({
"type": "webhook",
"payload": {"path": "/incoming", "body": request_body},
})
use iii_sdk::{FireTrigger, InitOptions, register_worker};
use serde_json::json;
let url = std::env::var("III_URL").expect("III_URL must be set");
let worker = register_worker(&url, InitOptions::default());
worker.fire_trigger(FireTrigger {
trigger_type: "webhook".into(),
payload: json!({ "path": "/incoming", "body": request_body }),
})?;
config (and optional condition_function_id), and invokes the bound function.
Unregister a trigger type
worker.unregisterTriggerType(type) removes the type at runtime. When the worker disconnects, all
trigger types it advertised are removed automatically and the engine stops routing events that
depended on them.
What goes in Worker Docs
The trigger type name, the config_schema shape, the event ordering guarantees, and any
back-pressure or retry semantics belong in this worker’s Worker Docs so consumers know what to
pass when they call registerTrigger. Keep iii-level concepts (the trigger binding model itself,
condition gates) here; document the per-type specifics there.
