> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iblueprint.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Automate iBlueprint workflows: schedule, webhook, Slack

> Run iBlueprint workflows on a schedule, via webhook, inbound email, Slack events, or a direct API call — without any manual intervention.

Triggers tell iBlueprint when to run a Blueprint. Instead of launching a Blueprint by hand every time, you can attach one or more triggers so the Blueprint fires automatically in response to external events, incoming messages, or a recurring schedule. iBlueprint supports six trigger types, and you can mix them on a single Blueprint.

## Add a trigger

<Steps>
  <Step title="Open Blueprint triggers">
    Open your Blueprint, then click **Triggers** in the top toolbar or sidebar panel.
  </Step>

  <Step title="Click Add trigger">
    Choose a trigger type from the list.
  </Step>

  <Step title="Configure the trigger">
    Fill in the settings for that trigger type (see the sections below).
  </Step>

  <Step title="Activate">
    Toggle the trigger **Active**. iBlueprint saves the configuration and begins listening immediately.
  </Step>
</Steps>

You can also fire any trigger manually from the trigger detail panel — useful for testing before you go live.

## Trigger types

<Tabs>
  <Tab title="Manual">
    A manual trigger has no automatic schedule or event. Use it to run a Blueprint on demand from the iBlueprint UI or by calling the fire endpoint from your own code.

    **Configuration:** none required.

    **When to use:** ad-hoc tasks, testing, or workflows that humans kick off after reviewing input data.
  </Tab>

  <Tab title="Scheduled">
    Runs the Blueprint on a cron schedule. iBlueprint uses standard five-field cron syntax.

    ```text theme={null}
    ┌───────── minute (0–59)
    │ ┌───────── hour (0–23)
    │ │ ┌───────── day of month (1–31)
    │ │ │ ┌───────── month (1–12)
    │ │ │ │ ┌───────── day of week (0–7, 0 and 7 = Sunday)
    │ │ │ │ │
    * * * * *
    ```

    **Common examples:**

    | Expression     | Meaning                              |
    | -------------- | ------------------------------------ |
    | `0 9 * * 1-5`  | Every weekday at 9:00 AM             |
    | `*/30 * * * *` | Every 30 minutes                     |
    | `0 0 1 * *`    | First day of every month at midnight |
    | `0 8,17 * * *` | Every day at 8:00 AM and 5:00 PM     |

    **When to use:** daily reports, nightly data syncs, recurring reminders, or any workflow that should run on a predictable cadence.
  </Tab>

  <Tab title="Webhook">
    iBlueprint generates a unique HTTPS URL for each webhook trigger. Any external system that sends a POST request to that URL will kick off the Blueprint, with the request body passed in as input data.

    **Setup:**

    1. After saving the trigger, click **Copy webhook URL** to get the generated endpoint:

       ```text theme={null}
       https://api.iblueprint.io/webhooks/blueprint/{trigger-id}
       ```

    2. Paste this URL into the external system (GitHub Actions, Stripe, your own backend, etc.).

    3. The external system sends a POST request with a JSON body whenever it needs to trigger the Blueprint.

    **Optional secret:** if a `secret` is configured on the trigger, iBlueprint checks the `X-Signature` header on incoming requests for HMAC verification. Generate and store the secret in both iBlueprint and your sending system.

    **When to use:** responding to events from external services — deployments, payment confirmations, form submissions, IoT signals.
  </Tab>

  <Tab title="Email">
    iBlueprint provisions an inbound email address for this trigger. Any email delivered to that address starts a Blueprint run, with the sender, subject, and body available as input data.

    **Configuration options:**

    * Filter by sender domain or address (optional).
    * Pass attachments to the Blueprint as file references.

    **When to use:** processing support requests, parsing structured reports delivered via email, or building email-to-workflow pipelines.

    <Note>
      The inbound email address is unique per trigger. Treat it as a secret — do not publish it publicly if your Blueprint performs sensitive actions.
    </Note>
  </Tab>

  <Tab title="Slack">
    Fires the Blueprint when a specified Slack event occurs in a connected workspace.

    **Configuration options:**

    * **Channel** — the Slack channel ID or name to listen on.
    * **Event type** — for example, `message`, `reaction_added`, or `app_mention`.

    **Setup:**

    1. Connect your Slack workspace under **Settings → Integrations → Slack** if you have not already done so.
    2. Select the channel and event type for this trigger.
    3. Save the trigger. iBlueprint registers the event subscription with Slack automatically.

    **When to use:** ChatOps workflows, monitoring Slack channels for keywords, responding to reactions, or letting team members trigger automations directly from Slack.
  </Tab>

  <Tab title="API">
    The API trigger exposes a named endpoint that you can call programmatically with a bearer token. Unlike a webhook, the API trigger is authenticated and intended for server-to-server calls from your own systems.

    **Configuration options:**

    * **Endpoint name** — a human-readable label for this trigger.
    * **Input schema** — optionally define the JSON fields your Blueprint expects as input.

    Call the trigger endpoint using your iBlueprint API key:

    ```bash theme={null}
    curl -X POST https://api.iblueprint.io/v1/triggers/{trigger-id}/fire \
      -H "Authorization: Bearer YOUR_API_KEY" \
      -H "Content-Type: application/json" \
      -d '{"userId": "u_123", "action": "welcome"}'
    ```

    **When to use:** integrating Blueprint runs into your own application backend, CI/CD pipelines, or any server-side process that should not be exposed to unauthenticated webhooks.
  </Tab>
</Tabs>

## Pass input data to a Blueprint

All trigger types (except manual) can pass structured data into the Blueprint at run time. This data is available to Blueprint nodes as the initial input payload.

For webhook and API triggers you control the JSON body directly. For email and Slack triggers, iBlueprint normalizes the inbound message into a consistent schema that your Blueprint nodes can reference.

## Deactivate or delete a trigger

* **Deactivate** — toggle the trigger off. The configuration is preserved and iBlueprint stops listening. You can reactivate it at any time.
* **Delete** — removes the trigger permanently. For webhook triggers, the generated URL stops accepting requests immediately.