Skip to main content
Triggers are entrypoints into a iii system. Each trigger defines the conditions that cause it to fire, a payload it accepts, and a function that it will invoke. When a trigger fires, the function is invoked with that payload.

Trigger Components

A trigger consists of three parts:
  1. Trigger Type: The mechanism that initiates execution (http, durable:subscriber, cron, log, stream)
  2. Configuration: Type-specific settings (path, schedule, topics)
  3. Function ID: The function to invoke when triggered

Trigger Pipeline

Core Trigger Types

HTTP Trigger (http)

Executes functions in response to HTTP requests. Provided by: HTTP Worker Configuration:
Input: ApiRequest with path params, query params, body, headers Output: ApiResponse with status_code, body, headers Conditions: Optional. Add condition_function_id to config with a function ID. The engine invokes it before the handler; if it returns false, the handler function is not called. See Trigger Conditions. Path Parameters: Extract values from URL

HTTP Worker

Learn more about the API trigger

The http Utility Function

The simple ApiResponse return pattern works well for JSON endpoints, but some use cases require full control over the response lifecycle — streaming a file download, sending Server-Sent Events, or setting headers incrementally. The http() utility function enables this. When you wrap your handler with an HTTP wrapper, it receives two arguments instead of one: the original request and a response object that gives you imperative control over the outgoing response:
The response object provides these capabilities across all SDKs: In Python, the http wrapper can be used as a decorator (@http) on an async def handler. The wrapped handler must be an async function that accepts (req: HttpRequest, response: HttpResponse) and optionally returns an ApiResponse. Import it with from iii import http. Under the hood, the wrapper unwraps the internal request, constructs the response object that maps status() and headers() calls to control messages sent over the underlying channel, and exposes the channel’s writable stream directly. This means you can pipe file streams, write SSE frames, or send any binary data through the response stream.
Use the HTTP wrapper when you need streaming responses. For simple JSON endpoints, returning a response dict/object directly is simpler and sufficient.

File Download

Use the HTTP wrapper to stream a file to the client without buffering the entire file in memory:
pipeline() handles backpressure and error propagation between the file read stream and the response write stream automatically.

Server-Sent Events (SSE)

SSE lets you push events from the server to the client over a single HTTP connection. Set the appropriate headers and write SSE frames to the response stream:
Each SSE frame follows the standard format: id, event, and data fields separated by newlines, with a blank line marking the end of a frame. Multi-line data values are split across multiple data: lines.

Queue Trigger (queue)

Executes functions when events are published to subscribed topics. Provided by: Queue Worker Configuration:
Input: Event payload (any JSON data) Output: Function result (optional, fire-and-forget pattern supported) Conditions: Optional. Add condition_function_id to config. See Trigger Conditions. Multiple Topics: Register separate triggers for each topic.

Queue Worker

Learn more about the Queue trigger

Cron Trigger (cron)

Executes functions on a time-based schedule using cron expressions. Provided by: Cron Worker Configuration:
Input: Cron execution context (timestamp, trigger info) Output: Function result Conditions: Optional. Add condition_function_id to config. See Trigger Conditions. Cron Expression: Standard 5-field format (minute hour day month weekday)

Cron Worker

Learn more about the Cron trigger

Log Trigger (log)

Executes functions when log entries match specified criteria. Provided by: Observability Worker Configuration:
Input: Log entry with trace_id, message, level, function_name, date Output: Function result (useful for alerting, metrics) Log Levels: info, warn, error, debug (omit to receive all levels)

Observability Worker

Learn more about the Log trigger

Stream Triggers (stream:join, stream:leave)

Executes functions when clients connect to or disconnect from streams. Provided by: Stream Worker Configuration:
Input: Subscription info with stream_name, group_id, item_id, context Output: Function result (useful for access control, analytics) Conditions: Optional. Add condition_function_id to config for stream:join/stream:leave. See Trigger Conditions.

Stream Worker

Learn more about Stream triggers

Trigger Type Comparison

Registering Triggers

Triggers are registered by workers after establishing a connection to the engine: Step 1: Register Function First, register the function that will be invoked:
Step 2: Register Trigger Then, register a trigger that routes to that function:
Step 3: Trigger Active The engine sets up the trigger in the appropriate module. When an HTTP POST request comes to /users, the users.create function will be invoked. Trigger types are registered by core modules during engine initialization:

Multiple Triggers to One Function

A single function can have multiple triggers:
Use Case: Send notifications via API calls, events, or scheduled jobs using the same logic.

Trigger Conditions

Triggers can optionally use a condition function to decide whether the handler should run. The engine invokes the condition with the trigger payload before the main handler. If it returns false, the handler is not invoked. Supported trigger types: http, durable:subscriber, cron, stream, state

How It Works

  1. Register a condition function that receives the same input as the handler and returns a boolean.
  2. Add condition_function_id to the trigger config with the condition function’s ID.
  3. When the trigger fires, the engine calls the condition first. Only if it returns truthy does the handler run.

Example: HTTP Trigger with Condition

Example: Queue Trigger with Condition

Example: State Trigger with Condition

Config Key

All trigger types use condition_function_id in the trigger config to reference the condition function.

Trigger Lifecycle

Unregistering Triggers

Remove triggers dynamically. registerTrigger returns a trigger object with unregister():

Usage Patterns

Webhook Handler

Event Chain

Scheduled Cleanup

Best Practices

Provide unique IDs for easier management:
Ensure trigger configuration matches what the function expects:
Use consistent path patterns:
Functions should handle errors gracefully:

Custom Trigger Types

Modules can register custom trigger types by implementing the trigger interface:

Next Steps

Modules

Explore modules that provide trigger types