The dispatch model
A hook is a small record: a topic, the tool to run, the keyword arguments to pass it, and an optional condition and expression over the payload. Registration is keyed by topic, so one topic can drive several hooks and the manager dispatches to all of them:The ingress door
External systems deliver events to the publicPOST /universal_webhook/{topic}
door. The payload parser accepts any content type, and the matched hooks run in the
background — the ingress returns without waiting for the tools to finish.
Managing hooks live
Hooks are managed at run time, with no restart. The manager comes in an in-memory and a Redis-backed form, and the authed management doors (GET/POST/DELETE
/api/hooks) are a thin skin over it — the same manager the hook-management
operations drive. Register and remove hooks from the
CLI:
register takes the whole hook record — topic, tool, kwargs, and an optional
condition — as one --params JSON object; its full option set is on the command
itself:
examples/hooks/register_hook.sh
PUT/DELETE /api/hooks/topics/{topic}/verifier).
See the fire-a-tool-from-a-webhook guide for
the binding-and-condition workflow, triggers and webhook
verifiers for authenticating the ingress, and
the HTTP API reference for the hook routes.
