email signal.
One automation can declare several triggers. If you’re migrating from a platform that routes events through sub-workflows, you can often keep those entrypoints and their work in one automation. Use merge when each event should run the same flow, or correlate when related events must meet. Use invokeAutomation when the target is independently useful, not only to connect steps within one process.
Declare triggers outside prerequisite sections. Each trigger occurrence starts an independent root context, so it can’t inherit a dependency from another trigger as part of starting that context. Automate.ax rejects trigger declarations inside withPrerequisites(...) and branch(...) during planning. Declare both triggers independently and use correlate to join their keyed signals.
Some compositions declare hidden triggers. Durable delays, provider callbacks, and polling actions can therefore add roots even when your source contains one visible trigger. Action context-boundary validation makes you connect literal actions to the root that should run them instead of allowing the same side effect to run once for every root.
Call triggers by service
Import the named service namespace from an integration entry point. Trigger members start withon and the event, such as gmail.onNewEmail and linear.onIssueCreated. These entry points also retain fully qualified callable exports such as onGmailNewEmail for direct per-trigger imports. Built-in triggers omit the provider, as in onSchedule and onHttpRequest.
Configure subscriptions and read events
Trigger arguments configure the subscription. The returned signal contains one matching event:Keep trigger configuration static
Automate.ax configures event infrastructure during deployment, before runtime values exist. Configuration that selects an event source, such as the account watched bygmail.onNewEmail, must therefore be static. A signal can’t choose the trigger’s account at runtime.
Action account options are different: an action may select an account from a signal because Automate.ax resolves that selection when the action executes. See Integration accounts.
Handle duplicate deliveries
Automate.ax manages provider subscriptions, renewal, ingestion, and durable delivery. Providers can send duplicate notifications. Integrations deduplicate them by provider identity when supported. An event accepted by the active deployment keeps its own execution context. Actions in that context consume only its trigger and action outputs.Authorize provider callbacks
UseonHttpRequest({ protection: "callback" }) when an action gives an HTTP callback URL to an external provider. Protected callbacks always use trigger scope, so the signed URL targets that exact endpoint and automation.
An action handler calls runtime.createCallbackUrl(endpoint) to turn the trigger’s deployed endpoint into a signed, expiring URL:
correlate to join them.
The same URL can accept provider retries. Automate.ax removes its protection parameter before exposing url and query in the trigger data. Provider delivery IDs and correlation still own deduplication and idempotency.
Respond to requests
HTTP triggers normally acknowledge accepted work immediately. Passingrequest.requestId to respondToHttpRequest addresses the response to that exact request and makes ingress wait automatically unless waitForResponse explicitly overrides the behavior. This remains unambiguous when an automation correlates several HTTP requests.
Ingress waits up to 55 seconds for the addressed response. If the execution finishes without one, ingress returns 500. If execution is still active after 55 seconds, ingress returns 504, and execution can continue after the caller times out.
If Automate.ax doesn’t provide the event you need, see Receive unsupported events for how to receive it with an HTTP webhook.