Firing a tool from a webhook
The webhook path reuses two existing pillars. An external system delivers an event to the public/universal_webhook/{topic} door; a hook bound to
that topic then runs its tool in the background. So “fire a tool from a webhook” is:
map a topic to a tool with a hook, and point the provider’s webhook at that topic.
Webhook verifiers
The public webhook doors —/universal_webhook/{topic} and the
interactions callback — authenticate an inbound request
over its raw bytes, before parsing, through a named verifier resolved from the
webhook-verifier registry. A topic with no verifier binding is open by design; you
bind a verifier to lock it.
Verification fails closed: a signature mismatch returns a constant 401, and a
missing verifier or secret returns a 500 — either way nothing is recorded and no
tool runs.
The built-in shared-secret verifier
The skeleton ships ashared_secret verifier that checks a named request header
against a secret read from an environment variable, with a constant-time compare.
Its config names the header and the env var holding the secret:
Scheduled triggers
The other trigger is time. A backend schedule fires a tool on a cadence or at a later time, naming the tool and its arguments — no external event required.The always-on public-door rate limiter guards both public families
(
/universal_webhook/* and the interactions callback), so an open door never ships
without flood control. Tune it with TAI_RATE_LIMIT_* environment settings.