feat(blocks): add Webhook tool for sending HTTP requests

[DeepakSilaych]

Adds a new Webhook tool block that allows sending HTTP requests to external webhook endpoints. This fixes the bug where users couldn't find a Webhook option in the Human in the Loop notification section as documented.

The block has category: 'tools' so it appears in:

• Human in the Loop notification dropdown (fixes the reported bug)
• Agent block's tool selector (enables agents to call webhooks)

Fixes #2379

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

1. Open a workflow with a Human in the Loop block
2. Click the Notification field
3. Verify "Webhook" now appears in the tool dropdown
4. Configure URL, method, headers, and body
5. Test the webhook sends correctly when HITL pauses

Also verify the Webhook tool appears in Agent block's tool selector.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Screenshots/Videos

[vercel]

@DeepakSilaych is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Overview

Greptile Summary

Adds a new Webhook tool block that enables sending HTTP POST/PUT/PATCH requests to external endpoints. The block properly integrates with the existing architecture by:

• Using category: 'tools' so it appears in both the Human in the Loop notification dropdown and Agent tool selector
• Leveraging the existing http_request tool for actual request execution
• Following the established block configuration pattern with proper inputs/outputs and subBlocks
• Including AI-assisted JSON body generation via wandConfig

The implementation correctly fixes issue #2379 where users couldn't find a Webhook option in the HITL notification section.

Confidence Score: 4/5

• This PR is safe to merge with minor style improvements recommended
• The implementation correctly solves the reported bug and follows existing patterns. Only minor style inconsistencies exist with the icon import (uses lucide-react directly instead of @/components/icons). The block properly integrates with the http_request tool and HITL system.
• No files require special attention - the style issues are minor and optional

Important Files Changed

File Analysis

Filename	Score	Overview
apps/sim/blocks/blocks/webhook_notification.ts	4/5	adds new Webhook tool block with HTTP request support; minor style issue with icon import pattern
apps/sim/blocks/registry.ts	5/5	correctly imports and registers the new WebhookNotificationBlock in alphabetical order

Sequence Diagram

sequenceDiagram
    participant User
    participant HITL as Human in the Loop Block
    participant Webhook as Webhook Notification Block
    participant HTTPTool as http_request Tool
    participant External as External Webhook Endpoint

    User->>HITL: Configure notification
    HITL->>HITL: Show tool dropdown (category: 'tools')
    User->>Webhook: Select "Webhook" from dropdown
    User->>Webhook: Configure URL, method, headers, body
    
    Note over HITL: Workflow pauses
    
    HITL->>Webhook: Trigger notification
    Webhook->>HTTPTool: Execute with params (url, method, headers, body)
    HTTPTool->>External: Send HTTP request (POST/PUT/PATCH)
    External-->>HTTPTool: Return response
    HTTPTool-->>Webhook: Return {data, status, headers}
    Webhook-->>HITL: Notification sent
    
    Note over HITL: Wait for approval
    
    User->>HITL: Approve/Resume
    HITL->>User: Workflow continues

Loading

[greptile-apps]

Additional Comments (3)

1. apps/sim/blocks/blocks/webhook_notification.ts, line 5 (link)

   style: use WebhookIcon from @/components/icons instead of lucide-react for consistency with other blocks

   _{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

2. apps/sim/blocks/blocks/webhook_notification.ts, line 1-6 (link)

   style: remove unused createElement import and helper function since we should use WebhookIcon from @/components/icons

   _{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

3. apps/sim/blocks/blocks/webhook_notification.ts, line 20 (link)

   style: reuse the same icon reference pattern used in the existing WebhookBlock at apps/sim/blocks/blocks/webhook.ts:42

   _{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

_{2 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[DeepakSilaych]

I did consider the minimal fix: just include the existing api block in the tool-input filter so it shows up in HITL notifications. That would be a ~1-line change and would technically solve the “no webhook option” problem.

I chose the dedicated Webhook tool (category tools) because:

• The HITL “Notification” UI is conceptually “pick a tool to notify”, and “Webhook” is clearer than “API” for most users.
• tool-input is reused in multiple places (Agent tools, HITL notifications, etc.), and keeping the selection semantics “tools = integrations” felt more consistent than mixing in a core blocks primitive.
• This avoids pushing users into the full API block UI (methods, query params, extra options) when the common use case is “send a POST to a webhook URL”.

That said, if we prefer the smallest diff and don’t mind API appearing in that dropdown, the 1-line filter change is a valid alternative.

[OverSamu]

If we choose to use the api block, wouldn't it be enough to move it to the tools category, instead of changing the tool-input filter?

sim/apps/sim/blocks/blocks/api.ts

Line 15 in f9cfca9

category: 'blocks',

[OverSamu]

Can this be merged?