Webhooks

Webhooks allow external services to trigger workflow execution from external webhooks by sending HTTP requests to your workflow. Mandala supports two approaches for webhook-based triggers.

Generic Webhook Trigger

The Generic Webhook block creates a flexible endpoint that can receive any payload and trigger your workflow:

How It Works

1. Add Generic Webhook Block - Drag the Generic Webhook block to start your workflow
2. Configure Payload - Set up the expected payload structure (optional)
3. Get Webhook URL - Copy the automatically generated unique endpoint
4. External Integration - Configure your external service to send POST requests to this URL
5. Workflow Execution - Every request to the webhook URL triggers the workflow

Features

• Flexible Payload: Accepts any JSON payload structure
• Automatic Parsing: Webhook data is automatically parsed and available to subsequent blocks
• Authentication: Optional bearer token or custom header authentication
• Rate Limiting: Built-in protection against abuse

Trigger Mode for Service Blocks

Alternatively, you can use specific service blocks (like Slack, GitHub, etc.) in "trigger mode" to create more specialized webhook endpoints:

Setting Up Trigger Mode

1. Add a trigger-capable service block - Drag it from the Triggers tab of the toolbar (not the regular Blocks tab) -- this is what puts it into trigger mode, there's no separate toggle to switch a block afterward
2. Configure Service - Set up authentication and event filters specific to that service
3. Webhook Registration - The service automatically registers the webhook with the external platform
4. Event-Based Execution - Workflow triggers only for specific events from that service

When to Use Each Approach

Use Generic Webhook when:

• Integrating with custom applications or services
• You need maximum flexibility in payload structure
• Working with services that don't have dedicated blocks
• Building internal integrations

Use Trigger Mode when:

• Working with supported services (Slack, GitHub, etc.)
• You want service-specific event filtering
• You need automatic webhook registration
• You want structured data handling for that service

Supported Services for Trigger Mode

30+ service blocks support trigger mode, including:

• Slack - Messages, mentions, reactions
• GitHub - Push, PR, issue events
• Airtable - Record changes
• Telegram - Bot messages and commands
• Gmail - Email notifications
• WhatsApp - Messaging events
• Jira - Issue updates, comments
• Linear - Issue state changes
• Stripe, Microsoft Teams, Calendly, HubSpot, Ashby, Clerk, Greenhouse, Lemlist, Vercel, Webflow, Typeform, Google Forms, PagerDuty, RevenueCat, Outlook, and more

WhatsApp trigger notes

• The WhatsApp Webhook trigger can optionally download inbound media (image/video/audio/document/sticker) and expose it as attachments so you can pass the files to downstream blocks (including OpenAI).
• Enable Download Media Attachments, then provide a WhatsApp Access Token with permission to fetch media via the Cloud API.
• Secret fields support environment-variable references: type {{ to insert/select an env var (e.g. {{WHATSAPP_ACCESS_TOKEN}}).

Security and Best Practices

Authentication Options

• Bearer Tokens: Include Authorization: Bearer <token> header
• Custom Headers: Define custom authentication headers

Payload Handling

• Validation: Validate incoming payloads to prevent malformed data
• Size Limits: Webhooks have payload size limits for security
• Error Handling: Configure error responses for invalid requests

Testing Webhooks

1. Use tools like Postman or curl to test your webhook endpoints
2. Check workflow execution logs for debugging
3. Verify payload structure matches your expectations
4. Test authentication and error scenarios

Common Use Cases

Real-time Notifications

• Slack messages triggering automated responses
• Email notifications for critical events

CI/CD Integration

• GitHub pushes triggering deployment workflows
• Build status updates
• Automated testing pipelines

Data Synchronization

• Airtable changes updating other systems
• Form submissions triggering follow-up actions
• E-commerce order processing

Customer Support

• Support ticket creation workflows
• Automated escalation processes
• Multi-channel communication routing

Trigger Health & Automatic Disabling

Polling-based triggers (IMAP, Gmail, Outlook, RSS) don't just retry forever when something goes wrong. Mandala tracks each trigger's failure history and will automatically disable a trigger that's stuck failing, so a permanently broken integration doesn't sit there silently retrying — and burning resources — forever.

Failures are treated differently depending on whether retrying could plausibly help:

• Permanent failures — bad credentials, missing required configuration, a feed URL that no longer exists — disable the trigger after just 3 consecutive failures. There's nothing to wait out, so it fails fast.
• Transient failures — connection refused, a timeout, a dropped TLS handshake, an upstream 5xx — get much more runway, tolerating up to 30 consecutive failures before disabling, since these often self-resolve on their own.

A failure streak only counts consecutive failures: if more than 2 hours pass without a failure, the next failure starts a fresh streak instead of adding to a stale count. This means occasional, self-resolving blips spread out over time don't quietly accumulate toward the disable threshold — only an unbroken run of failures does.

What to Do If You Get a Disable Notification

1. Fix the underlying issue - Update expired credentials, correct configuration, or confirm the external service/feed is reachable again.
2. Re-enable the trigger - Reactivate it (or redeploy the workflow) so it resumes polling.