> ## Documentation Index > Fetch the complete documentation index at: https://learn.getodin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Core Triggers > General-purpose triggers for manual runs, scheduled execution, HTTP requests, and file uploads. Core triggers cover the most common workflow entry points: manual invocation, scheduled runs, incoming HTTP requests, and file uploads. ## Manual Input Starts a workflow when a user or external system explicitly invokes it. You can configure it with custom input fields that must be filled in before the workflow runs — making it ideal for on-demand tasks that require user-provided context, such as submitting a request, kicking off a report, or initiating a process from within the Odin chat interface. **When to use it** * You want to run a workflow on demand from the Odin UI or via the API. * The workflow needs user-provided inputs before it can execute. * You are testing or debugging a workflow with specific values. **Configuration** | Field | Type | Description | | ------------ | ---- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Input fields | Any | User-defined parameters configured in the trigger settings. Each field has a name, type, and optional description shown to the user at runtime. | **Output variables** | Variable | Description | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | `trigger.user_input` | The raw text submitted by the user. | | `trigger.inputs.` | The value of each named input field. Replace `` with the configured field name (e.g., `trigger.inputs.customer_name`). | | `trigger.chat_id` | The ID of the chat session that initiated the run. | | `trigger.message_id` | The ID of the message that triggered the workflow. | ```text Example: referencing an input field theme={null} Hello {{ trigger.inputs.customer_name }}, your request has been received. ``` * Input fields are presented to the user as a form before the workflow starts. Keep field names short and descriptive. * `trigger.user_input` is available even if no custom input fields are configured. * To invoke this trigger programmatically, call the Odin API with the workflow ID and the required input values. ## Webhook Exposes a unique HTTP endpoint for your workflow. External systems — such as third-party applications, automation platforms, or custom scripts — can send an HTTP request to that URL to start the workflow. The request body, headers, query parameters, and HTTP method are all passed to downstream nodes. **When to use it** * An external system needs to notify Odin when an event occurs (e.g., a form submission, a payment event, or an update from another platform). * You are integrating Odin with Odin AI or another system that can call an HTTP endpoint. * You want to expose a workflow as an API endpoint that other developers or tools can call. **Configuration** | Setting | Type | Description | | --------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `http_method` | String | The HTTP method the endpoint will accept: `GET`, `POST`, `PUT`, `PATCH`, or `DELETE`. | | `auth_type` | String | How incoming requests are authenticated: `none`, `basic`, or `header`. | | `response_mode` | String | `onReceived` returns an immediate HTTP 200 as soon as the request arrives. `lastNode` waits for the workflow to complete and returns the final output as the HTTP response. | **Output variables** | Variable | Description | | --------------------- | ------------------------------------------------------------------------------------------------------------ | | `trigger.body` | The JSON body of the incoming request. | | `trigger.headers` | The HTTP headers sent with the request. | | `trigger.query` | URL query parameters from the request. | | `trigger.method` | The HTTP method used by the caller. | | `trigger.webhook_url` | The full URL of the webhook endpoint. Share this with the external system that will be calling the workflow. | **Response modes** | Mode | Behavior | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `onReceived` | Returns HTTP `200 OK` immediately when the request arrives, before the workflow finishes. Use for fire-and-forget scenarios. | | `lastNode` | Holds the HTTP connection open until the workflow completes, then returns the final node output as the response body. Use when the caller expects a synchronous payload. | * When using `header` auth, configure the expected header name and value in the trigger settings. * `trigger.webhook_url` is useful for including the endpoint URL in setup documentation sent to integration partners. * If you are calling this webhook from Odin AI, use the **HTTP Task** action in your bot to POST to the webhook URL. ## Schedule Fires a workflow automatically on a recurring schedule defined by a cron expression. Use it to automate time-based tasks such as daily reports, periodic data syncs, or recurring notifications — without any manual intervention. **When to use it** * You need a workflow to run at a fixed time every day, week, or month. * You are automating a recurring business process (e.g., pulling data every morning, sending a weekly summary). * You want to poll an external system at regular intervals. **Configuration** | Setting | Type | Description | | ---------- | ------ | ---------------------------------------------------------------------------------------------------------------------------- | | `schedule` | String | A cron expression defining when the workflow runs. | | `timezone` | String | The timezone in which the cron expression is evaluated. Accepts standard timezone names such as `UTC` or `America/New_York`. | Always set the `timezone` field explicitly. If left unset, the schedule runs in UTC, which may cause unexpected timing for region-specific workflows. **Cron expression reference** A cron expression has five fields: **minute · hour · day of month · month · day of week**. ```text theme={null} ┌───── minute (0–59) │ ┌───── hour (0–23) │ │ ┌───── day of month (1–31) │ │ │ ┌───── month (1–12) │ │ │ │ ┌───── day of week (0–6, Sunday = 0) │ │ │ │ │ * * * * * ``` | Expression | Schedule | | -------------- | ----------------------------------- | | `0 9 * * *` | Every day at 9:00 AM | | `0 9 * * 1` | Every Monday at 9:00 AM | | `0 */6 * * *` | Every 6 hours | | `0 8 1 * *` | First day of every month at 8:00 AM | | `*/15 * * * *` | Every 15 minutes | **Output variables** | Variable | Description | | ----------------------------- | -------------------------------------------------- | | `trigger.trigger_time` | The ISO 8601 timestamp of when the schedule fired. | | `trigger.schedule_expression` | The cron expression used for this run. | | `trigger.trigger_type` | Always `"schedule"`. | * The Schedule trigger does not pass user input. If your workflow needs dynamic data, fetch it inside the workflow using an API node or toolkit tool. * Use `trigger.trigger_time` in downstream nodes to stamp records or log when the scheduled run occurred. ## File Upload Starts a workflow when one or more files are uploaded. It provides each file's content, name, size, and MIME type to downstream nodes — making it ideal for document processing workflows such as parsing an uploaded report, extracting data from a spreadsheet, or routing a file to an AI model for analysis. **When to use it** * You want users to submit files for the workflow to process (e.g., invoices, contracts, CSV exports). * You need to extract content from uploaded documents and pass it to an LLM or data processing node. * You are building a multi-file ingestion pipeline. **Configuration** This trigger has no required configuration fields. It activates automatically when a file is uploaded to the workflow's associated chat or interface. **Output variables** | Variable | Description | | ---------------------- | -------------------------------------------------------------- | | `trigger.file.content` | The full extracted text content of the uploaded file. | | `trigger.file.name` | The original filename. | | `trigger.file.size` | The file size in bytes. | | `trigger.file.type` | The MIME type (e.g., `application/pdf`, `text/csv`). | | `trigger.file_count` | Total number of files uploaded. Returns `1` for a single file. | | Variable | Description | | -------------------- | ----------------------------------------------------------------------------------------- | | `trigger.files` | An array of all uploaded files. Each item contains `content`, `name`, `size`, and `type`. | | `trigger.file_count` | Total number of files uploaded. | Use a **Loop** node to iterate over `trigger.files` when processing multiple uploads in a single run. File content is extracted as plain text. Binary formats such as PDFs and Word documents are parsed automatically — the extracted text is what appears in `trigger.file.content`. * `trigger.file` always refers to the first (or only) uploaded file. For multi-file workflows, use `trigger.files` with a Loop node. * Use `trigger.file.type` in a Conditional node to route different file types to different processing branches.