Outgoing Webhooks

What are Outgoing Webhooks?

Outgoing webhooks allow you to send data from Tadabase to external services and applications automatically when specific events occur in your app. When a record is created, updated, or deleted, the webhook sends the record data to a destination URL of your choice.

Please Note: Webhooks are included with subscription plans of Pro and above.

Why Use Outgoing Webhooks?

Outgoing webhooks are valuable for triggering actions outside of Tadabase based on events that happen inside your app. Common use cases include:

• Sending notifications to Slack or Microsoft Teams
• Triggering WhatsApp messages via Twilio
• Adding data to Google Sheets
• Sending batch emails through external services
• Syncing data with external databases or CRM systems
• Triggering automation workflows in tools like Make, Zapier, or n8n
• Maintaining offsite backups of records

Getting Started

Before creating a webhook in Tadabase, you need a destination URL where the data will be sent. This could be:

• A Slack webhook URL (learn more)
• A Twilio WhatsApp API endpoint (learn more)
• An automation platform like Make, Zapier, or n8n
• Your own custom API endpoint
• A webhook testing service like webhook.site

Creating an Outgoing Webhook

Step 1: Access Webhooks

Navigate to the Automation tab in your app builder and click on Outgoing Webhooks. Then click the Create a New Webhook button.

Step 2: Configure Basic Settings

A new window will prompt you to configure the following settings:

Webhook Name

Give your webhook a descriptive name to easily identify its purpose. This is especially helpful when managing multiple webhooks.

Description

Add notes about what this webhook does, its purpose, or any important details. This helps with documentation and team collaboration.

Data Table

Select the data table that will trigger this webhook. The webhook will only fire when events occur on records in this specific table.

Target URL

Enter the destination URL where the webhook data will be sent.

Important: Your URL must begin with "https://" for security reasons.

Event Type

Select when the webhook should be triggered:

1. New Record - When a record is created
2. Update Record - When a record is edited
3. Delete Record - When a record is deleted

Status

Set the webhook as Active to enable it or Inactive to temporarily disable it without deleting the configuration.

Understanding Event Types

New Record

When a new record is created, the webhook sends all newly created values along with the record ID to your destination URL.

Update Record

When a record is updated, the webhook behavior depends on how the update was made:

• Inline Editing: Only the field that was edited inline will be sent with the record ID
• Form Submission: Only the fields present in the form will be sent with the record ID
• API Update: Only the fields included in the API request will be sent

Delete Record

When a record is deleted, all fields and values from that record are sent with the webhook. This is commonly used for maintaining offsite backups of deleted records. To learn more about backing up deleted records, see our webhook backup guide.

Webhook Trigger Behavior

Important notes about when webhooks are triggered:

Please Note: Your webhook will run regardless of where the change originated - whether from the Builder, a form, a record rule, or direct table interaction in your live app.

API Events: By default, webhooks are NOT triggered by API calls. If your app requires webhooks to fire from API events, please contact support to have this enabled for your account.

Advanced Features

Conditional Webhooks

You can add conditions to control when webhooks are triggered. For example, only send the webhook if a status field equals "Active" or if a priority field is "High". This prevents unnecessary webhook calls and gives you precise control over when data is sent to external services.

Conditional logic allows you to:

• Filter which records trigger the webhook based on field values
• Create complex AND/OR condition groups
• Compare field values against specific criteria
• Reduce webhook usage by only sending relevant data

Conditional Field Values

Set field values dynamically based on conditions. For instance, if a status equals "Active", automatically set a priority field to "High". This eliminates the need for separate automation steps by embedding logic directly in the webhook configuration.

Benefits include:

• Smart Logic: Automatically transform data based on custom conditions
• Streamlined Workflows: Reduce the number of automation steps needed
• Flexible Configuration: Apply multiple conditions with fallback values

Validation Rules

Add validation rules to incoming webhook data to ensure data quality before records are created or updated. Rules can check for required fields, valid formats, or specific value ranges. This prevents incomplete or incorrect data from being saved in your database.

Webhook Folders

Organize related webhooks using folders. This feature helps keep complex automations organized and makes it easier to manage multiple webhooks across large projects.

Custom Headers and Authentication

Webhooks support custom headers for authentication and security. You can include API keys, authorization tokens, or custom headers required by your destination service. Security enhancements include signature support for webhook verification to ensure requests are legitimate.

Webhook Processing

Queue-Based Execution

Outgoing webhooks run asynchronously in a queue system. This means:

• Webhooks typically execute very quickly but are not instant
• The queue prevents server overload when sending many webhooks
• Webhooks are processed in batches for optimal performance
• Your app remains responsive even when sending large numbers of webhooks

Immediate Processing Option

For scenarios requiring instant responses (such as returning a new record ID), you can enable immediate webhook processing. This skips the job queue and processes the webhook in real-time.

Performance Optimization

For high-volume payloads, you can enable optimization mode to handle webhook requests up to 50x faster. This is ideal for batch operations or large data transfers.

Error Handling and Retry Logic

Automatic Retries

If a webhook fails to deliver successfully, the system automatically retries up to 5 times before marking it as failed. This handles temporary network issues or service outages gracefully.

Failure Notifications

You will receive email notifications when webhooks fail repeatedly:

• After 5 failures: First alert notification
• After 20 failures: Critical failure notification

These alerts help you identify and resolve issues with your webhook configurations or destination services quickly.

Common Error Types

The webhook logging system captures detailed error information including:

• Connection Errors: DNS resolution failures, connection refused, timeouts
• HTTP Errors: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Server Errors
• SSL/Certificate Errors: Invalid or expired SSL certificates
• Rate Limiting: 429 Too Many Requests from the destination service
• Timeout Errors: Request took too long to complete

Testing Your Webhooks

For testing purposes, we recommend using webhook.site, which generates a unique URL to catch webhooks and display the payload:

Testing Steps

1. Go to webhook.site and copy the generated unique URL
2. Paste the URL into your Tadabase webhook configuration
3. Trigger the webhook by creating, updating, or deleting a record
4. Return to webhook.site to view the received data and payload structure

Manual Re-Run

You can manually re-trigger any webhook from the webhook logs interface. This is useful for:

• Testing webhook configurations
• Retrying failed webhook deliveries
• Sending historical data to newly configured endpoints

Monitoring Webhook Activity

Each webhook includes a Logs tab where you can:

• View all webhook executions with timestamps
• See success or failure status for each attempt
• Review error messages and diagnostic information
• Check the data that was sent in each webhook
• View the most recent activity directly on the webhook page

For detailed information on webhook logging, see our Outgoing Webhook Logs guide.

Webhook Data Format

Request Format

Outgoing webhooks send data as form-encoded parameters (not JSON) via HTTP POST requests. The payload includes:

• Record ID: The unique identifier for the record (encoded)
• Field Data: All relevant field values based on the event type
• Field Types: Different field types are formatted appropriately (dates, connections, files, etc.)

Payload Example

When a webhook is triggered, the receiving endpoint will receive data similar to this:

id: abc123xyz
field_31: John Doe
field_32: john@example.com
field_33: 2025-01-14
field_34: Active

Plan Limits and Usage

Outgoing webhook availability and limits depend on your subscription plan:

• Feature Availability: Pro plans and above
• Webhook Limit: Maximum number of active webhooks per app (varies by plan)
• Log Retention: Webhook logs are retained for a specified number of days (typically 30 days)
• Usage Tracking: Webhook executions are tracked for analytics and billing purposes

Contact support or view your plan details to understand your specific webhook limits.

Sample Webhook Receiver Script

Here is a sample Python Flask script to receive and process Tadabase webhooks:

from flask import Flask, request, Response
import os
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

@app.route('/webhook',methods=['POST'])
def webhook():
    print("Data received from Webhook is: ", request.form)
    data = request.form

    print(data['id'])
    print(data['field_31'])
    return Response("okay", status=200)

host = 'localhost'

if __name__ == '__main__':
    app.debug = True
    port = int(os.environ.get("PORT", 8080))
    app.run(host='0.0.0.0', port=port)

Best Practices

• Descriptive Naming: Use clear, descriptive names and descriptions for each webhook
• Test First: Always test webhooks with webhook.site before connecting to production services
• Use Conditions: Apply conditional logic to reduce unnecessary webhook calls
• Monitor Logs: Regularly check webhook logs for failures or issues
• Organize with Folders: Group related webhooks in folders for better management
• Secure Endpoints: Always use HTTPS and implement proper authentication on receiving endpoints
• Handle Errors Gracefully: Ensure your receiving endpoint can handle retries and returns proper status codes
• Document Integrations: Use the description field to document what each webhook does

Related Articles

• Incoming Webhooks
• Webhooks Overview
• Outgoing Webhook Logs
• Using Webhooks to Save Deleted Records