> For the complete documentation index, see [llms.txt](https://documentation.astera.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.astera.com/astera-studio/automations/triggers.md).
# Triggers
A **trigger** is what tells an automation *when* to run. Every automation has exactly one trigger, chosen on the **Trigger** step of the creation wizard. Some triggers fire on a clock, some fire when something happens inside Astera Studio, and some fire when a third-party service posts an event to a URL you give them. This article covers each trigger type, the options it exposes, and — in detail — how to set up and secure a **webhook** trigger.
The Trigger step is part of the automation wizard. To reach it, open **Manage > Automations**, start a new automation with **+ New automation**, complete the **Basics** and **Action** steps, and then open the **Trigger** step.
Click **Choose a trigger** to open the trigger picker. From here you can search by name or vendor, or browse by category in the left sidebar. You can change the trigger at any time later.
## Trigger categories
The picker organizes every trigger into four categories. The count beside each category shows how many trigger types it contains.
* **Time-based** triggers fire on a clock — *once*, *hourly*, *daily*, *weekly*, or *monthly*. These are the most common kind.
* **Event-based** triggers fire when something happens rather than when the clock ticks — for example, when a file lands or an email arrives. They are ideal for reactive pipelines.
* **Webhook sources** fire when a third-party service (GitHub, Jira, Stripe, and others) posts an event to a URL Astera mints for you. Astera ships ready-made templates for popular vendors and supports a custom webhook for anything else.
* **In-process** triggers run relative to Astera itself — a *continuous* loop that fires as soon as the previous run finishes, and a *manual* trigger that only runs when you click **Run**.
After you pick a trigger type, the picker closes and that trigger's configuration fields appear directly on the Trigger step.
## Time-based triggers
Time-based triggers run your automation on a fixed cadence. Five options are available.
* **Once** — runs a single time at a date and time you choose, then never again.
* **Hourly** — runs every *N* minutes or every *N* hours.
* **Daily** — runs every day, on weekdays only, or every *N* days, at a time you set. (Marked *Popular*.)
* **Weekly** — runs on the weekdays you pick, at a fixed time.
* **Monthly** — runs on a specific day of the month, or on the *nth* weekday (for example, the *third Tuesday*).
## Event-based triggers
Event-based triggers react to something happening rather than to the clock. Open the **Event-based** category in the picker to see the available event types and configure the condition each one watches for.
## In-process triggers
In-process triggers are driven by Astera Studio itself rather than by an external schedule or service.
* **Continuous** fires as soon as the previous run completes — a hot loop with a configurable wait time between passes. Use this for near-real-time pipelines where you always want the freshest result.
* **Manual** has no configuration. The automation never fires on its own; it only runs when you click **Run**. This is useful for automations that act as named, saved playbooks — audited and reusable, but not scheduled.
## Webhook triggers
A **webhook** trigger lets an outside service start your automation. You select a vendor, Astera mints a unique URL for you, and you paste that URL into the vendor's webhook settings. From then on, every event the vendor sends to that URL fires your automation.
Open the **Webhook sources** category to browse the available vendors. Each vendor that is commonly used is marked *Popular*.
### Available webhook vendors
Astera Studio ships built-in templates for the vendors below, plus a **Custom Webhook** option for anything not on the list. The **What secret you handle** column tells you, in practical terms, what you'll be asked to do during setup:
* **Vendor gives you the secret** — the vendor generates a signing secret; you copy it and paste it into Astera.
* **Astera generates the secret** — the vendor doesn't sign its events, so security relies on the unguessable URL Astera mints; there is no secret to paste.
* **Either** — you can paste a vendor secret *or* leave it blank and let Astera mint one for you.
| Category | Vendor | What secret you handle |
| ------------------- | ------------------------------------------- | --------------------------- |
| Dev / Ops | **GitHub** *(Popular)* | Either |
| Dev / Ops | **GitLab** *(Popular)* | Astera generates the secret |
| Dev / Ops | **Bitbucket Cloud** | Either |
| Dev / Ops | **Atlassian Jira** *(Popular)* | Astera generates the secret |
| Dev / Ops | **Linear** *(Popular)* | Vendor gives you the secret |
| Dev / Ops | **Sentry** *(Popular)* | Vendor gives you the secret |
| Dev / Ops | **PagerDuty** | Vendor gives you the secret |
| Dev / Ops | **GitHub (legacy SHA-1)** | Either |
| Payments / Commerce | **Stripe** *(Popular)* | Vendor gives you the secret |
| Payments / Commerce | **Shopify** | Vendor gives you the secret |
| Payments / Commerce | **Square** | Vendor gives you the secret |
| Productivity | **Asana** *(Popular)* | Vendor gives you the secret |
| Productivity | **Trello** | Vendor gives you the secret |
| Productivity | **Notion** | Vendor gives you the secret |
| Productivity | **Calendly** | Vendor gives you the secret |
| Productivity | **Typeform** | Vendor gives you the secret |
| CRM / Support | **HubSpot** *(Popular)* | Vendor gives you the secret |
| CRM / Support | **Zendesk** | Vendor gives you the secret |
| CRM / Support | **Intercom** | Vendor gives you the secret |
| CRM / Marketing | **Meta (Facebook / Instagram)** *(Popular)* | Vendor gives you the secret |
| CRM / Marketing | **Google Ads (Lead Forms)** *(Popular)* | Astera generates the secret |
| CRM / Marketing | **Klaviyo** | Astera generates the secret |
| CRM / Marketing | **Customer.io** | Vendor gives you the secret |
| CRM / Marketing | **Webflow** | Vendor gives you the secret |
| CRM / Marketing | **Mailchimp** | Astera generates the secret |
| Communication | **Slack** *(Popular)* | Vendor gives you the secret |
| Communication | **Zoom** | Vendor gives you the secret |
| Communication | **Twilio** | Vendor gives you the secret |
| Custom | **Custom HMAC** | Either |
{% hint style="info" %}
The vendor catalog is maintained centrally, so the exact list you see may grow over time. The event names shown in each vendor's setup are examples only — vendors publish many more, and Astera does not restrict you to the listed names (see **Event filter** below).
{% endhint %}
### Custom Webhook
If your service isn't in the vendor list, use **Custom Webhook** (available from the bottom of the picker). A custom webhook works the same way as a vendor template, except you supply the details the template would normally pre-fill — such as how the sender signs its requests and where to read the event name from. Choose this when you're integrating an in-house service or a vendor Astera doesn't yet template.
### Setting up a webhook (Atlassian Jira example)
The setup flow is the same for every vendor. We'll use **Atlassian Jira** as the example.
When you first select Jira, the trigger shows a **SETUP** badge and the status *Token not yet issued* — no URL exists yet. An expandable **Atlassian Jira setup guide** is available inline for vendor-specific instructions.
Scroll to the **Issue webhook URL** card and click **Issue token**. Issuing saves the automation and then mints a one-time URL and signing secret.
Astera then shows the **Webhook ready** panel with three values:
* **Webhook URL** — the delivery endpoint you paste into the vendor.
* **Bearer token** — the access token (already embedded inside the Webhook URL).
* **Signing secret** — used by the vendor to sign its deliveries, where applicable.
{% hint style="warning" %}
These values are shown **once**. Astera stores only a hash of the token and an encrypted form of the signing secret, so it can't display them again. Copy them now. If you lose them, rotating the token mints a fresh pair and invalidates the old one.
{% endhint %}
To finish, follow the steps in the **What to do next** box on that panel:
1. Open the vendor's webhook setup screen (for Jira: **Settings ⚙ → System → Webhooks → Create**).
2. Paste the **Webhook URL** as the delivery endpoint.
3. Paste the **Signing secret** into the vendor's signing-secret field (when the vendor uses one).
4. Trigger a test delivery from the vendor — Astera fires this automation on the next valid event.
### Event filter
The optional **Event filter** field narrows which incoming events fire the automation. Type an event name — for example, `customer.subscription.created` for Stripe or `jira:issue_created` for Jira — or pick a sample from the dropdown.
* The dropdown lists **common examples only**. Vendors publish many more event names; you can type any of them.
* If you **leave the filter blank**, every event the vendor sends to your URL fires the automation.
* For some vendors the event name is read from the request body, and for others from a request header — this is handled for you automatically; you only need the event name itself.
{% hint style="info" %}
Astera automatically de-duplicates deliveries for most vendors, so a vendor retrying the same event won't fire your automation twice. (A small number of vendors don't provide enough information to de-duplicate automatically.)
{% endhint %}
### Payload sent to the AI
When a webhook fires, Astera passes the incoming event to your automation's action (such as an AI task). The **Payload sent to the AI** setting controls how much of that event the action actually receives. This matters for both privacy and focus — you can hand over the whole event, a masked version, just the context, or only the specific fields you choose.
* **Full body** — everything is passed through verbatim, exactly as the vendor sent it. Use this when the action genuinely needs the complete event and the data is not sensitive.
* **Redacted body** *(default)* — the full body is passed, but common secrets are automatically masked first (for example, authorization tokens and similar sensitive fields). This is the safe default for most automations.
* **Metadata only** — no event body is passed. The action receives only the trigger context (such as which vendor fired and which event type), with none of the event's contents.
* **Custom (pick fields)** — you specify exactly which fields to forward using a JSONPath projection, and everything else is dropped. Use this when the action needs only a few values out of a large payload.
## Saving the trigger
Once your trigger is configured, click **Continue** to move on to the remaining wizard steps. Astera validates every step before you can save — if the trigger is incomplete, the **Save** button stays disabled and lists what's missing. For a full walkthrough of the wizard, see [Creating an Automation](https://documentation.astera.com/astera-studio/automations/creating-an-automation).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://documentation.astera.com/astera-studio/automations/triggers.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.