Skip to main content
Triggers connect an action to an entry point. A trigger selects the transport, maps transport data into action arguments, and optionally protects execution with an auth block.

HTTP Triggers

HTTP triggers expose actions as REST endpoints.
HTTP triggers support these request sources:

Entity arguments from path IDs

When an action argument is typed as an entity, you can bind it directly from a path-string ID. The runtime auto-resolves the path string into the entity instance for you — there is no need to declare a TEXT id parameter and then look the entity up with single Entity where @id == X.
The argument inside the action body is the resolved entity, so field access (e.g. todo.title) and relation traversal work as expected. This also applies to PUT /{collection}/{id} and DELETE /{collection}/{id} triggers that operate on a single resource. By default, an HTTP trigger returns the action result with status 200 and no extra headers. Override that with statusCode, body, and responseHeaders when the public API shape should differ from the action result.

Queues

Use a queue when a request should return quickly while background work continues.
Declare a queue with queue name with EntityType, enqueue with enqueue name with value, and consume with a trigger ... on Queue that maps @message.

Cron Triggers

Cron triggers run on a schedule and have no request or subject context, so they cannot use auth, @request, or @subject.
Schedules are plain cron strings. Use five-field cron expressions for minute-level schedules, or a seconds field when the local dev server needs sub-minute testing.

Event Triggers

Event triggers subscribe an action to an internal named event.
Event and queue triggers both use @message for their payload. The difference is how the message is produced: queues are explicit SLang queues, while events are named application events emitted by the runtime.