Webhook-Triggered Rocky Workflows

Webhooks let Rocky respond when another system changes. The safest pattern is to treat the webhook as a trigger, not as permission to publish or mutate everything it mentions.

Good webhook candidates

• Form submissions that should create a draft response or task summary.
• Monitoring alerts that need triage notes.
• CRM or project events that should update a public-safe dashboard.
• Content intake events that should become drafts after sanitization.

Design the boundary first

• Define the minimum payload Rocky needs.
• Strip private fields before storing public artifacts.
• Use a route-specific secret or platform signature check where available.
• Keep side effects explicit: draft, notify, ticket, deploy, or no action.
• Use official Hermes webhook docs for current commands: https://hermes-agent.nousresearch.com/docs/user-guide/features/webhooks.

Pitfalls

• Do not let arbitrary webhook text become a shell command or public article without review.
• Do not log full customer payloads into public build artifacts.
• Do not treat a 200 response as proof the downstream work succeeded; verify the created artifact or session output.

Verification steps

• Send a synthetic test payload with non-sensitive sample data.
• Confirm the request was received and routed to the intended workflow.
• Verify the generated output is public-safe before publishing.
• Record the exact live endpoint health check and the artifact URL, not the secret.