[Feature Request] Please add webhook-triggered Agent runs — fire-and-forget POST on completion
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
Research direction
Start by locating the existing Agent run entry point, audit trail, and grant or policy enforcement described in the issue. Map how inbound and outbound webhook configuration would fit those existing systems, then use the acceptance criteria to define completion, including validation, rate limiting, unchanged permissions, and audit records.
Written by the indexing model from the issue text.
Description
Problem
OpenBot has persistent coworkers, per-Agent computers, governed tool use, and auditability, but it lacks a simple way to trigger Agent runs from external events or notify external systems when a run completes.
For teams integrating OpenBot into existing workflows (e.g., CI/CD pipelines, monitoring alerts, newsletter automation), there is no way to kick off an Agent run via webhook or receive a notification when a run finishes. This forces manual intervention or polling, which defeats the purpose of autonomous Agents.
Feature request
Add webhook-triggered Agent runs — a fire-and-forget POST endpoint to start a run, and an optional outbound webhook when a run completes. This should be an event-layer feature, not a new scheduling system.
Proposed behaviour
- Allow configuring an inbound webhook URL per Agent that, when POSTed to, triggers a new run with the provided payload as context.
- Allow configuring an outbound webhook URL per Agent that receives a POST when a run completes (success, failure, or refusal).
- Support optional payload templates for outbound webhooks (e.g., include run ID, outcome, transcript summary).
- Validate inbound webhook payloads and show clear errors for malformed requests.
- Preserve all governance settings (grants, policies) for webhook-triggered runs, scoped to the Agent's existing permissions.
- Rate-limit inbound webhooks to prevent abuse (e.g., max 10 runs per minute per Agent).
Required controls
- Disabled by default; enabled per Agent.
- Webhook scope: per-Agent, not per deployment.
- Immutable audit log showing when a webhook triggered a run or was sent on completion.
- Review, edit, and delete controls for webhook URLs.
- Clear separation between webhook payload and runtime state (no arbitrary code execution from payload).
- Never automatically grant additional tools or permissions for webhook-triggered runs — grants are unchanged.
- Configurable allowlist for webhook sources (specific IPs, domains, or any URL).
Why this matters
This would make OpenBot more competitive for teams integrating Agents into existing automation workflows while preserving its core advantages: per-Agent isolation, gateway policy enforcement, and action-level auditability. It would be particularly useful for a self-hosted team that wants to trigger Agents from external events (e.g., "new issue filed", "site downtime detected", "newsletter draft due") without manual intervention.
Acceptance criteria
- An administrator can configure an inbound webhook URL for an Agent.
- An administrator can configure an outbound webhook URL for an Agent.
- POSTing to the inbound webhook triggers a new Agent run with the payload as context.
- Completing a run sends a POST to the outbound webhook with run metadata.
- All webhook triggers and sends appear in the existing audit trail.
- Invalid webhook payloads are rejected with clear error messages.
- Webhook-triggered runs respect the Agent's existing grant boundaries.
Suggested name
Webhook Triggers or Event-Driven Agent Runs
- Dominant language
- TypeScript
- Stars
- 6.3k
- Forks
- 863
- Avg merge
- 17h 38m
- Merged PRs (30d)
- 161
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CopilotKit/OpenBot
-
Wrong key location at startupPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 1/5 Under an hour Newbie friendliness 68/100
CopilotKit/OpenBot#800 ·
Maintainers usually reply within 1 day
-
setup-learning.ts fails on Windows with "spawn npx.cmd EINVAL"Possibly taken @Caldas claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
CopilotKit/OpenBot#792 ·
Maintainers usually reply within 1 day
-
Five out-of-subject findings from PR #770's tier-3 review (credential-revoking tests, single-user boot gate, OAuth client rotation, shared-use atomicity, untyped server/tests)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 Over a week Newbie friendliness 22/100
CopilotKit/OpenBot#786 ·
Maintainers usually reply within 1 day
-
server/tests leaks database connections: 55 files open a pool and never close itPossibly taken @adamsiwiec1 claimed this 2 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 70/100
CopilotKit/OpenBot#785 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
CopilotKit/OpenBot#783 ·
Maintainers usually reply within 1 day
All issues in CopilotKit/OpenBot
Similar issues
-
area:security documentation effort:S priority:P2
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
app:web meta:ops
Difficulty 2/5 Half a day Newbie friendliness 78/100
osu-tournament-rating/otr#1113 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
typegoose/mongodb-memory-server#1040 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 92/100