Troubleshooting

When a webhook fails, the HTTP status code tells you what went wrong. Here are the most common errors and how to fix them. Timeout (408) means your endpoint took longer to respond than the configured timeout — increase the timeout setting in your webhook configuration. Rate Limited (429) means the receiving service is throttling your requests — enable retry with exponential backoff so Chattlebot will automatically re-attempt the request with increasing delays. Server Error (500–504) indicates a problem on the receiving endpoint — check your endpoint's health, logs, and whether the service is experiencing an outage. Bad Request (400) usually means your payload doesn't match the format the API expects — verify your JSON syntax, check for missing required fields, and ensure variable names are correct. Authentication Failure (401/403) means your credentials are wrong, expired, or the token doesn't have the right permissions — verify your authentication settings and rotate tokens if needed. Network Error means Chattlebot couldn't reach your URL at all — verify the URL is correct, the server is publicly accessible, and you're using HTTPS. Start by looking at the error with the highest count in your health dashboard — fixing it will have the most impact.

Retry with exponential backoff helps your webhooks recover from transient failures automatically. When enabled, Chattlebot will re-attempt failed requests with increasing delays: 1 second after the first failure, 2 seconds after the second, and 4 seconds after the third. This backoff pattern prevents overwhelming a struggling endpoint while still giving it a chance to recover. Retryable status codes include: 408 (Timeout), 429 (Rate Limited), 500, 502, 503, and 504 (Server Errors). These are all situations where a retry might succeed because the issue is likely temporary. Non-retryable codes like 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), and 404 (Not Found) are NOT retried because they indicate a configuration problem that won't fix itself — you need to correct the payload, credentials, or URL. You can set the maximum number of attempts from 1 to 5 in your webhook settings. Each attempt is logged separately in the execution history, so you can see exactly which attempt succeeded and which ones failed.

The timeout setting controls how long Chattlebot waits for your endpoint to respond before giving up. The default is 10 seconds, and you can set it anywhere from 5 to 60 seconds. When to decrease (5–8s): Use shorter timeouts for simple notification endpoints like Slack webhooks, email triggers, or basic data logging — these should respond almost instantly, and a long timeout would just delay error detection. When to use the default (10s): The 10-second default works well for most CRM APIs, database operations, and standard webhook receivers. When to increase (15–30s): Use longer timeouts for AI/ML APIs (like OpenAI or enrichment services), endpoints that do database lookups, or APIs that process data before responding. When to use maximum (30–60s): Reserve the highest timeout values for batch operations, file processing, or slow third-party services that you know need extra time. For AI-callable webhooks, keep timeouts reasonable — the AI waits for the response during a live chat, so anything over 10 seconds will feel slow to the user.

Sometimes an HTTP 200 status code doesn't actually mean success. Some APIs return 200 OK but include an error in the response body, like {"status": "error", "message": "Duplicate entry"}. Without a success condition, Chattlebot would mark this as a successful execution because the HTTP status was 200. To catch these cases, configure a success condition with two fields: a JSONPath expression that points to the field you want to check (e.g., $.status), and an expected value that field should contain (e.g., "success"). When a success condition is configured, Chattlebot checks both the HTTP status code AND the response body. The execution is only marked as successful if the HTTP status is in the success range (200–299) AND the JSONPath field matches the expected value. This is especially important for workflow webhooks where subsequent steps depend on the webhook actually succeeding, and for AI-callable webhooks where a false success could lead to the AI presenting incorrect data to users.

Here are answers to the most frequently asked webhook questions. 'Works in test but not on real leads' — The most common cause is that the trigger settings aren't configured correctly. Check that the Lead Capture trigger is enabled and that the urgency filter isn't set too restrictively (e.g., High only when most leads come in as Medium). Test mode uses sample data and always fires regardless of trigger settings. 'Getting duplicate calls' — This happens when the same webhook has both Lead Capture and AI-Callable triggers enabled. A single conversation might trigger both — the lead capture fires when the visitor submits info, and the AI tool fires if the AI needs data during the same chat. Solution: use idempotent endpoints that handle duplicate calls gracefully, or use upsert logic in your receiving system. 'Variables are empty in the payload' — Double-check your variable names against the Payload Reference guide. Variables are case-sensitive and must use the exact format: {{lead.email}}, not {{Lead.Email}} or {{lead_email}}. Also verify the data actually exists — for example, {{lead.phone}} will be empty if the visitor didn't provide a phone number. 'Zapier webhook stopped working' — First check if the Zap is paused in your Zapier dashboard — Zapier automatically pauses Zaps that haven't triggered in a while or if there are repeated errors. Also verify the webhook URL hasn't changed (Zapier generates a new URL if you recreate the trigger).

Before contacting support, follow this debugging checklist to gather the information you need. Step 1: Check the health dashboard — look at success rates and error trends over the last 24 hours and 7 days to understand the scope of the problem. Step 2: Review the execution logs — find the specific failed execution and note the timestamp, status code, trigger type, and response body. Step 3: Check the error breakdown — identify which error category your failure falls into and try the suggested fix. Step 4: If the issue persists after following the suggestions, contact support with three pieces of information: your webhook ID (found in the webhook settings), the error status code and response body from a recent failed execution, and the timestamp of the failure. This gives our support team everything they need to investigate quickly. You can reach support through the help menu in your dashboard or by emailing support@chattlebot.com.