Skip to main content
Your compose tasks can be triggered by several different mechanisms. Triggers are configured in your manifest file for each task. Each task can have multiple triggers (one of each type), so triggers are configured as an array. Below is an overview of all the supported trigger types: cron, http, and onchain_event.

Local Task Execution

For locally testing tasks you can use the callTask CLI command. This works regardless of what trigger types a task has configured (and even for tasks with no triggers at all).

Trigger Task locally with CLI

Task Code

Task To Task Execution

Tasks can call other tasks directly — no trigger configuration required on the called task. This is done using the callTask context function.

Example

The process-data task will receive the payload and can return a response:

Chain Event Triggers

Tasks can be triggered by onchain events. The payload delivered to the task is the raw encoded log. Compose provides helpers for decoding the event in your task code — see Contracts for more details on decoding.
Onchain event triggers only fire when your app is deployed to the cloud. They do not fire during local development. To test a task with an onchain trigger locally, use callTask with a sample event payload:
You can copy a real event payload from a block explorer to use as test data.

Example event object sent as the payload to your task:

Example configuration for an onchain event trigger:

Task code

Here’s an example in which we decode the event with a contract class we’ve generated with goldsky compose codegen, see Contracts for more info.

Onchain Trigger Properties

Failure Handling

Onchain-triggered tasks honor the task’s retry_config. When a task throws (or otherwise fails), Compose retries it up to max_attempts with the configured backoff. If every attempt fails, that event is dropped and the pipeline advances to the next one — it is not replayed. This means an unhandled exception in an onchain-triggered task only stalls delivery for the duration of your retry window, not indefinitely. If you want a failure to be visible without consuming retries, catch the error in your task and return normally — the run is recorded as successful and the pipeline moves on.

Cron Triggers

Tasks can be triggered on a schedule. Tasks triggered by cron are invoked with an empty payload ({}), since each invocation is generic.

Example

6-field (second-granularity) example

Pass a 6-field expression if you need second-level precision — the first field becomes seconds:

Cron Trigger Properties

HTTP Triggers

Tasks can be triggered by HTTP requests. This is often used to kick off compose tasks from your application logic. HTTP triggers accept any JSON payload you want for dynamic execution.

Example

Http Trigger Properties

Authenticated triggers require a Goldsky API token when the app is deployed, but can be called without auth when testing locally. Unauthenticated triggers can be called without auth both locally and when deployed.

Base URL

Locally, Compose runs on http://localhost:4000 by default. If port 4000 is taken, start picks the next free port up to 4009 and records it in .compose/.port. The base pattern for all task endpoints is:
When deployed to the cloud, tasks with an authenticated HTTP trigger (authentication: "auth_token") are reachable at:
When deployed to the cloud, tasks with an unauthenticated HTTP trigger (authentication: "none") are reachable at:

HTTP Request Format

When deployed to the cloud with authentication: "auth_token", you’ll need to pass a Goldsky API token:

Execute HTTP trigger without parameters

Execute an HTTP trigger with parameters

Response Format

Tasks return JSON responses with the data returned by the task’s main function. Calling this task:
via this request:
returns this JSON response:

Next Steps

Using Packages

You can use any sandbox compatible typescript packages with any package manager.

Debugging

Debug and monitor your apps