Pipeline Trigger Types

Every pipeline must have an entry point. Without one, the pipeline cannot execute.

What is an Entry Point?

The entry point defines which node executes first when your pipeline runs and controls how the pipeline is triggered. When a node is designated as the entry point, a Trigger selector appears inside the node body, letting you choose between three trigger modes: Chat Message, Schedule, and Webhook.

Key Rules

Single Entry Point

Exactly one node must be designated as the entry point. Pipeline execution always begins at this node. Setting a new entry point automatically removes the previous designation.

Auto-Assignment

When the first node is added to an empty pipeline, it is automatically designated as the entry point. Only Condition and End nodes are excluded from auto-assignment.

Can Be Entry Points

LLM, Agent, Toolkit, MCP, Code, Printer, Router, State Modifier, HITL, Subgraph, Custom

Cannot Be Entry Points

Condition (deprecated), Decision

Setting an Entry Point

Visual Method (Flow Editor)

Open your pipeline in the Flow Editor
Expand the node card by clicking on it
Click the three dots (⋮) in the node header
Select Make entrypoint from the dropdown

Once a node is designated as the entry point, an entry point icon appears in its header and the Trigger selector becomes visible inside the node body.

Setting a new entry point automatically removes the previous designation. The “Make entrypoint” option only appears when a node is expanded and is not already the entry point.

YAML Method

In YAML configuration, declare the entry point at the top level using the node’s id:

entry_point: greeting

nodes:
  - id: greeting
    type: llm

The YAML key order is: state → entry_point → interrupt_after → interrupt_before → nodes.

Trigger configuration (schedule, webhook) is stored server-side and is not part of the pipeline YAML. The YAML only contains the entry_point node ID.

Trigger Type

When a node is the entry point, a Trigger dropdown appears inside the node body. This controls how the pipeline is started.

Chat Message

Default trigger. The pipeline runs each time a user sends a message in a chat session. Required for interactive pipelines with HITL or Printer nodes.

Schedule

Runs automatically at a defined time using a cron expression. Supports a visual cron builder or raw cron input.

Webhook

Allows external systems to trigger the pipeline via HTTP POST. Supports GitHub, GitLab, and Custom webhook types.

Schedule and Webhook triggers are unavailable when the pipeline contains HITL nodes, Printer nodes, or interrupt configurations. Only Chat Message is available for interactive pipelines.

If the pipeline includes a toolkit that requires OAuth authorization (for example, Azure SharePoint Delegated, or an MCP toolkit configured with OAuth), all trigger options in the Trigger dropdown are currently disabled, not only Schedule and Webhook. Only the Chat Message trigger is guaranteed to work for such pipelines.

Chat Message

The default trigger. The pipeline runs each time a user sends a message in a chat session.

Required when the pipeline contains HITL nodes, Printer nodes, or any interrupt_before / interrupt_after configurations
If an interactive element (HITL, Printer) is added while Schedule or Webhook is active, the trigger automatically resets to Chat Message

Schedule

The pipeline runs automatically at a defined time using a cron expression. Selecting Schedule opens a configuration modal with two modes:

Mode	Description
Builder	Visual cron builder — choose a Day, Week, or Month frequency and configure the corresponding fields interactively
Cron Expression	Enter a raw cron expression manually

Default cron expression: 0 0 * * 6 (every Saturday at midnight)
Timezone is automatically detected from your browser settings
Cron format: minute – hour – day (month) – month – day (week)

Schedule Information: Once a schedule is configured, the pipeline’s INFORMATION accordion (in the left panel) displays:

Field	Description
Trigger	Shows `Schedule`
Schedule	The configured cron expression
Timezone	The timezone used to calculate run times
Last run	Timestamp of the most recent scheduled execution
Next run	Timestamp of the next scheduled execution, calculated from the cron expression, timezone, and current date and time

Next run information refreshes automatically after you update the schedule, turn it on or off, or the pipeline executes. See INFORMATION for the full list of fields shown in this accordion.

Webhook

The pipeline runs when an external system sends an HTTP POST request to the generated webhook URL.

Selecting Webhook opens a configuration modal. Three webhook subtypes are available:

Type	Auth Header	Signature Method
GitHub	`X-Hub-Signature-256`	HMAC-SHA256 (`sha256=<computed_hmac>`)
GitLab	`X-Gitlab-Token` or `webhook-signature`, depending on the selected authentication method — see below	Secret token, or HMAC-SHA256
Custom	`X-Webhook-Token`	Secret token sent directly in the header

The modal shows:

Field	Description
Webhook URL	Read-only, automatically constructed based on the selected type. Use the copy button to copy it.
Authentication (GitLab only)	Choose between Secret token and Signing token — see GitLab Authentication Methods below
Secret token	A 32-byte base64url token generated automatically. Can be shown or hidden, copied, or regenerated. Click Apply to save a regenerated token. Not shown when GitLab’s Signing token method is selected.
Example request	A ready-to-use example showing the exact headers and payload format for the selected webhook type and authentication method.

GitHub example:

curl -X POST "https://your-elitea-instance/webhook/github" \
  -H "Content-Type: text/plain" \
  -H "X-Hub-Signature-256: sha256=<computed_hmac>" \
  -d 'Your message or data here'

GitLab example (Secret token):

curl -X POST "https://your-elitea-instance/webhook/gitlab" \
  -H "Content-Type: text/plain" \
  -H "X-Gitlab-Token: <your_secret>" \
  -d 'Your message or data here'

GitLab example (Signing token):

POST https://your-elitea-instance/webhook/gitlab
webhook-id: <delivery id>
webhook-timestamp: <unix seconds>
webhook-signature: v1,<base64 hmac-sha256>

# GitLab sends these headers itself; the only thing you configure in GitLab is the URL above.

Custom example:

curl -X POST "https://your-elitea-instance/webhook/custom" \
  -H "Content-Type: text/plain" \
  -H "X-Webhook-Token: <your_secret>" \
  -d 'Your message or data here'

GitLab Authentication Methods

Selecting GitLab as the webhook type reveals an Authentication choice with two methods:

Method	Who generates the token	Header checked
Secret token (default)	ELITEA — you paste ELITEA’s generated value into GitLab’s “Secret token” field	`X-Gitlab-Token`
Signing token	GitLab — you paste GitLab’s generated value into ELITEA	`webhook-signature` (plus `webhook-id` and `webhook-timestamp`)

Existing GitLab webhooks keep working unchanged — Secret token is the default and matches the original behavior. Switching to Signing token does not erase the secret-token value; switching back later restores it.

With Signing token selected, the modal replaces the generated Secret Value field with a Signing token input: paste the value GitLab displays when you enable the webhook (format whsec_<base64> — GitLab shows it only once). ELITEA cannot generate or regenerate this value; it only checks that the pasted value starts with whsec_ and decodes to a usable key. There is no show/hide or copy control for it, since it is never generated by ELITEA. ELITEA validates each delivery by checking the webhook-signature header (format v1,<base64 HMAC-SHA256>, computed over "{webhook-id}.{webhook-timestamp}.{raw request body}") and rejects any delivery whose webhook-timestamp is more than 5 minutes away from the current time. X-Gitlab-Token is not required or checked in Signing token mode.

Best Practices

Match trigger to workflow type

Use Chat Message for interactive conversational pipelines; use Schedule for automated batch processing; use Webhook for event-driven integration with external systems.

Interactive pipelines require Chat Message

Any pipeline with HITL or Printer nodes must use the Chat Message trigger. Schedule and Webhook triggers are automatically disabled for such pipelines.

Match entry_point value to a node id

In YAML configuration, ensure the entry_point value exactly matches a node id defined in the nodes list.

Protect webhook secrets

Regenerate the secret if it is ever exposed. Always copy it immediately after generation — it cannot be retrieved once the modal is closed without regenerating. For GitLab’s Signing token method, there is no regenerate option in ELITEA — generate a new signing token in GitLab itself and paste the new value in.

Prefer GitLab's Signing token method

GitLab’s Secret token method sends the token in a plain header on every delivery; Signing token instead has GitLab sign each delivery with HMAC-SHA256 and includes replay protection (deliveries older than 5 minutes are rejected). Prefer Signing token for new GitLab webhooks when your GitLab instance supports it.

Node Connectors - Connect nodes to create workflows
State Management - Understand state in pipelines
Flow Editor - Visual pipeline building
Control Flow Nodes - Router and Decision nodes
YAML Configuration - Complete YAML syntax reference

Chats

Indexing

Agents, Pipelines & Skills

Credentials & Toolkits

Entity Management

What is an Entry Point?

Key Rules

Single Entry Point

Auto-Assignment

Can Be Entry Points

Cannot Be Entry Points

Setting an Entry Point

Visual Method (Flow Editor)

YAML Method

Trigger Type

Chat Message

Schedule

Webhook

Chat Message

Schedule

Webhook

GitLab Authentication Methods

Best Practices

​What is an Entry Point?

​Key Rules

Single Entry Point

Auto-Assignment

Can Be Entry Points

Cannot Be Entry Points

​Setting an Entry Point

​Visual Method (Flow Editor)

​YAML Method

​Trigger Type

Chat Message

Schedule

Webhook

​Chat Message

​Schedule

​Webhook

​GitLab Authentication Methods

​ Best Practices

What is an Entry Point?

Key Rules

Setting an Entry Point

Visual Method (Flow Editor)

YAML Method

Trigger Type

Chat Message

Schedule

Webhook

GitLab Authentication Methods

Best Practices