The goal of this cookbook is to empower you to integrate webhooks from any external service into your application, enabling real-time event handling and automation. This cookbook focuses on foundational principles, teaching you to “fish” by understanding the core setup patterns, verification methods, and integration strategies.
POST requests and headers.This section covers shared fundamentals. Use these as building blocks for any webhook integration. We’ll reference them in the examples.
Apply core concepts to configure listeners for specific services. These examples demonstrate patterns for signature verification (GitHub) and verification challenges (Zoom). For each, we explain the rationale behind configurations, how fields interconnect, and how to adapt them based on service docs. This teaches you to analyze new services: Identify their verification type, map request elements to Agent Studio fields, and build responses that align with expectations.
GitHub webhooks notify your endpoint of repository events like pushes or pull requests. They use optional signature verification for security, with no initial challenge. This pattern is common for services prioritizing payload integrity over setup ceremonies.
Registration establishes the shared secret and URL. In GitHub:
repository > Settings > Webhooks > Add webhook.https://your-instance.moveworks.ai/webhooks/v1/listeners/your-listener/notify). This is where GitHub sends POST requests.application/json.Upon saving, GitHub sends a “ping” event (identified by header x-github-event: ping). This tests connectivity but doesn’t require special handling, treat it as a valid event.
Signature verification ensures authenticity. GitHub signs the raw body with HMAC-SHA256, sending the result in a header. In Agent Studio’s Verification panel:
Signature Verification (HMAC).HMAC-SHA256, matching GitHub’s algorithmraw_body. GitHub signs the unparsed bytes, so this preserves exact contentheaders["x-hub-signature-256"]. This header includes a sha256= prefix, which Agent Studio infers and strips during comparisonThese fields interconnect: The payload feeds into HMAC with the secret and mode, producing an expected signature matched against the received one
Zoom webhooks notify your endpoint of events like meeting starts or ends. They require an initial URL validation challenge and support signature verification for events. This dual pattern teaches handling setup trust (challenge) separately from ongoing security (signature), common in services with periodic re-validation.
Registration triggers the challenge. In Zoom:
Zoom uses a challenge for URL validation and signatures for events. Configure both.
In the One Time Verification Challenge panel:
parsed_body.event == "endpoint.url_validation" using Moveworks DSL. (detects the validation POST).200 OK. Zoom expects success codes; mismatches fail validation.zoom_token (or any unique identifier). This name becomes a reference key, use it in the response body as shown above challenge_token["zoom_token"] to insert the computed hash dynamically.HMAC-SHA256parsed_body.payload.plainTokenIn the Verification panel:
HMAC-SHA256.$CONCAT([headers["x-zm-request-timestamp"],":",raw_body],""). This builds the exact string Zoom signs.headers["x-zm-signature"].