Webhook-triggered scheduled tasks via the T3 Connect relay

[pzep1]

Summary

I'd like to add webhook-triggered automations to scheduled tasks, so an external event (GitHub, CI, monitoring, etc.) can start a run. I've been running the orchestrator v2 branch and have a working implementation. I opened a PR for it prematurely (my bad), so I'm opening this discussion to check the direction with maintainers first.

Motivation

Scheduled tasks only run on a timer today. Being able to say "run this task when X happens" would cover things like triaging a failed CI run or reacting to a new issue.

Proposed approach

The first version piggybacks on the existing T3 Connect relay Worker, so there's no new service.

Relay

• POST /v1/inbox/:id stores the request and returns 202.
• A queue consumer pushes it to the environment over the managed tunnel as a relay-signed request to /api/t3-connect/webhook-delivery. It's verified the same way as the health check, with a digest binding the proof to the delivery.
• The relay deletes a delivery only after the environment's signed ack verifies.
• Queue retries and the five-minute cron cover offline machines. Deliveries expire after 7 days.

Server

• Each delivery starts one run. The message is the task's instructions plus the request as received, marked as untrusted data.
• The command id is keyed on the delivery id, so a redelivery can't start a second thread.
• Agents can't create webhook URLs through MCP.

Clients

• An "On a webhook" option in the task editor (web and mobile), a URL card with copy, and a project-settings entry.

Limits

• Bodies up to 256 KB, at most 100 pending deliveries per inbox, and delivery only to tunnel-linked environments.

Deploy footprint

• One migration (two tables), one queue plus a dead-letter queue, and one step in the existing five-minute cron.

Tradeoff / known gap

This requires T3 Connect with remote access. Machines that aren't linked, or are linked for notifications only (publish_only), can't use webhook schedules. The server refuses to create an inbox for them, and the editor explains why. Local and Tailscale-only setups need a direct ingress path, which is out of scope here. A self-deployed relay worker would largely close that gap.

Questions

• Is building on the T3 Connect relay acceptable as a first step?
• Would you want a direct-ingress option for non-Connect setups, and if so, in this effort or separately?
• Any concerns with the signing, ack, or untrusted-data handling?

Prior work

I opened a PR prematurely. It was closed by the bot, but it has an indicative implementation: #14600.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the proposal. Webhook-triggered scheduled tasks have now landed on main through the T3 Connect relay:

• #15085 adds the webhook trigger on the server (secret URL, optional HMAC signature check, rate limit, and delivery log).
• #15086 has the relay forward webhook requests to the environment's tunnel.
• #15087 and #15088 add create, copy, and rotate on mobile and web, plus a deliveries view on web.
• #15487 adds an opt-in to hold webhooks on the relay while the environment is offline.

Closing this as resolved. Please open a new discussion or issue for anything the shipped version doesn't cover.