---
title: "Automations"
description: "Run agent prompts on webhooks and schedules"
canonical_url: "https://hoplite.sh/docs/automations"
markdown_url: "https://hoplite.sh/docs/automations.md"
---

# Automations
URL: /docs/automations
LLM index: /llms.txt
Description: Run agent prompts on webhooks and schedules
Related: /docs/threads/run, /docs/prompting, /docs/integrations/slack, /docs/integrations/linear

# Automations

Automations run an agent prompt against a project without anyone typing it — triggered by an incoming webhook or on a schedule. Use them for recurring chores (dependency bumps, triage sweeps, report generation) or to wire external systems into Hoplite.

## Create an automation

Each automation belongs to a project and has:

| Field | Purpose |
| --- | --- |
| Name | Identifies the automation |
| Enabled | Toggle it on or off |
| Prompt | What the agent should do, written exactly like a thread message |
| Run title (optional) | Title for the runs it creates |
| Trigger | A webhook or a schedule |

Workspace owners, admins, and members can create, run, enable, edit, and delete
automations. Viewers can inspect automations and their run history but do not
see mutation controls.

<Callout type="tip" title="Write prompts like standing orders">
The prompt runs unattended, so spell out the goal, the constraints, and what "done" looks like — e.g. "Check for outdated dependencies with known CVEs. If any exist, upgrade them, run the test suite, and open a draft PR summarizing the changes. If tests fail, stop and report instead of forcing the upgrade."
</Callout>

## Trigger from a webhook

A webhook automation has a fixed delivery endpoint and a bearer token. Send the token in the `Authorization` header:

```bash
curl -X POST https://api.hoplite.sh/api/automations/webhooks \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"event":"deploy.failed"}'
```

An authenticated `POST` runs the automation's prompt as a new agent run. The token is scoped to that one automation — it can't read data or trigger anything else. Treat it like any other secret and only copy it into the system that delivers the webhook.

### Manage the token

- Open **Edit automation** to review and copy the request, endpoint, or bearer token again
- **Rotate** the token any time from the automation's page; rotation replaces the stored credential, so the old token stops working immediately
- Legacy `hwa_` credentials that cannot be displayed must first be rotated, which invalidates the old token

<Callout type="warning" title="Legacy token-in-path URLs">
Legacy `hwa_` token-in-path URLs remain available during a compatibility window; the legacy route can be removed after it reports no deliveries for 90 consecutive days. New and rotated `hwa2_` credentials are header-only and are rejected in URL paths.
</Callout>

## Run on a schedule

Scheduled automations run on either:

- **Cron** — a standard 5-field cron expression with an IANA timezone (e.g. `0 9 * * 1` in `Europe/Dublin` for Mondays at 9:00)
- **Interval** — a fixed period, minimum 1 minute

The automations page shows each automation's last run, its status, and when it fires next.

## Inspect the runs

Every trigger does the same thing: starts a new thread and agent run in the project with the automation's prompt. The run behaves like any other — full [sandbox](/docs/sandboxes), full [tool catalog](/docs/agent/tools), and a complete activity timeline. The run history on an automation links directly to the thread once it has been created, so you can inspect the result or continue the work there.

## Sitemap

See the full [sitemap](/docs/sitemap.md) for all pages.
Well-known sitemap: [/docs/.well-known/sitemap.md](/docs/.well-known/sitemap.md).