Triggers (entry points)

How an invocation begins. The three entry node kinds (entry_api, entry_webhook, entry_schedule) compile to top-level IRTrigger declarations on IRModule.triggers, NOT to blocks inside flow.body. The runtime walks the trigger list to know which inbound events should kick off which flows.

The closed set#

IRTrigger.kind ∈ {api, webhook, schedule} — these are the only three values ScaiCore's parser accepts. There is no fourth kind. In particular:

• There is no chat trigger. Chat reachability is a publish-time concern handled by flow.config.publish_as_model. When true, the deploy step calls POST /v1/modules/scaicore/cores/{id}/publish, which registers a FrontendModel reachable via /v1/chat/completions at slug scaicore/{tenant}/{core.slug}. See Publish as model.
• There is no message trigger. A documentation example in ScaiGrid's manifest YAML once showed trigger: {type: message, ...} — that was a doc bug; the YAML loader never honored it.

Per-kind shape#

entry_api#

{ "type": "entry_api", "config": { "method": "POST", "path": "/" } }

After deploy, invoked via:

1
2
3
4

curl -X POST "https://scaigrid.scailabs.ai/v1/modules/scaicore/cores/${CORE_ID}/invoke" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"input": {"message": "hello"}}'

The payload's input becomes the trigger's emitted scope (visible as out_request on the downstream port).

entry_webhook#

{ "type": "entry_webhook", "config": { "method": "POST", "path": "/", "auth": null } }

Same wire shape as entry_api. The distinction is mostly documentary — webhook flags that the source is an external system (Stripe, GitHub, etc.) rather than first-party application code. The auth field is reserved for future signature-verification metadata.

entry_schedule#

{ "type": "entry_schedule", "config": { "cron": "0 * * * *", "timezone": "UTC" } }

Standard 5-field cron. The runtime fires the trigger in the configured timezone — pick UTC for cross-region deployments unless you have a specific reason not to.

Multiple entries per flow#

Nothing stops a single flow from having multiple entries. The YAML emitter surfaces the first entry as the canonical trigger and adds extra entries as additional flow declarations with the same step list. The IR codegen creates one IRTrigger per entry, all pointing to the same target_flow name.

In practice, multiple entries are unusual — most flows have one input shape they're built around. If you find yourself adding a second entry of a different kind to the same flow, consider whether you actually want two flows that share a sub-flow (see Sub-flows).