Webhooks #

Webhooks let Your AI Connector automatically notify your other business tools whenever something important happens — a new contact being created, an appointment being booked, a message being received. Instead of manually checking for updates, your connected systems get an instant notification the moment something happens.

What Are Webhooks? #

Think of a webhook like an automatic text message between two apps. When something happens in Your AI Connector (like a new contact signing up), the platform instantly sends a notification to another system of your choice. You provide a web address (called a “webhook URL”) where these notifications should be sent — this is typically provided by your CRM, automation platform, or developer.

Webhooks only send data OUT of Your AI Connector. A webhook is a one-way street from Your AI Connector to your other tools. There is no webhook URL that sends leads, contacts, or messages INTO the platform. To push a new lead in — from a website form, your CRM, or GoHighLevel — your system makes an API call instead. See API Access (the Create a Contact operation) and Funnels. The only thing you need for the inbound direction is your API key, which lives in its own section — see API Access. The Webhooks page described here is exclusively for the outbound direction.

Common uses include:

• Syncing new contacts to your CRM.
• Triggering a workflow in Zapier, Make, or Pabbly when a tag is applied.
• Notifying your team in Slack when a human is alerted.
• Updating your calendar system when an appointment is booked.
• Logging conversation summaries to your database.

Setting Up Webhooks #

1. In the left sidebar, click Settings (gear icon).
2. In the Settings sidebar, under the Integrations group, click Webhooks.

On an account with no webhooks configured yet, the page looks like this:

3. Click New webhook, top-right. A form opens inline on the page:

4. Fill in:
   • Endpoint URL — the web address Your AI Connector will send event notifications to. You get this from your external system (CRM, automation platform, or custom server).
   • Name — a label you’ll recognize later (e.g. “Slack alerts” or “CRM sync”). For your reference only.

Your webhook URL must be a publicly reachable https:// address. Plain http:// addresses, localhost or private-network addresses, and platform-internal addresses are rejected when you save. To test from your own machine, use a public tunnel (webhook.site or ngrok) instead of localhost.

5. Under Events, click the events you want this webhook to receive — all 22 are listed in The 22 Webhook Events.
6. (Optional) Turn on Retry failed deliveries if you want Your AI Connector to keep trying on a temporary failure — see Retrying Failed Deliveries.
7. Click Create webhook. It appears in the list below the form, and you can click Test on its row any time to fire a sample payload at your endpoint.

Permission needed. Adding, editing, or testing webhooks requires the Integrations “edit” permission (view-only team members see a read-only notice instead of the form).

Signing a webhook requires it to already be saved first — open an existing webhook’s row to edit it, and the Signing secret panel appears at the bottom of the edit form. A brand-new, unsaved draft has no signing option yet — see Signed Payloads below.

One Webhook for All Your Client Accounts (Agencies) #

If you run an agency, you don’t have to re-create the same webhook on every client account. On the agency account, the webhook form has an extra toggle: Also fire for all client accounts. Turn it on and this webhook also receives events that happen on every client account under your agency — one endpoint, whole agency.

How it behaves:

• The user block tells you which client an event belongs to. Every notification already carries a user block identifying the account the event happened on, so your automation can route per client.
• Your webhook’s own settings apply everywhere. The events you selected, the signing secret, and the retry setting are used for client-account deliveries too.
• No double deliveries. If a client account has its own webhook pointing at the same URL, that one is used for that account’s events instead — the same event never arrives twice at one endpoint.
• Clients don’t see it. The webhook does not appear on the client account’s own Webhooks page, and clients can’t switch it off — it’s yours to manage.
• Reliability is tracked per client account. If your endpoint keeps failing, it is switched off automatically for the account whose deliveries failed (see Webhook Reliability), not for the whole agency at once.

The toggle only appears on agency accounts. Setting it over the API is also supported — see the apply_to_sub_accounts field in the Webhooks API.

Available Trigger Events #

You can enable or disable each of the 22 webhook events independently. When an event fires, Your AI Connector sends a notification to your webhook URL with the relevant data. Every event, what it means, and the event code it puts in the payload are listed together in The 22 Webhook Events further down this page.

Good to know: Task Created, Task Updated, and Task Completed are fully selectable and save correctly. Daily Summary Created is also a recent addition. See Task Completed Webhook below for that payload shape.

Tag-Based Webhook Triggers #

subscribed_to_tags does not scope a webhook’s events to a tag. It only narrows which tags produce a conversation-summary notification. To get a request when a specific tag is applied, set a webhook URL on that tag in the Tags tab of the agent (or campaign).

The webhook form itself has no tag picker, either when creating a new webhook or when editing one, so subscribed_to_tags can only be read or changed through the Webhooks API, or by asking support.

Good to know: editing an existing webhook that has a subscribed_to_tags list (renaming it, changing its events, toggling retries) no longer clears that list — since the form has no tag picker to send back, saving from this page now leaves the existing list untouched. (This was a real bug before July 21, 2026: saving from the webhook form used to erase the list because it always sent an empty tag list. If a webhook lost its subscribed_to_tags list before that date, it will need to be reconfigured through the API.)

Generate Summary for Tagged Contacts #

Where a webhook has a subscribed_to_tags list, you can turn on Generate Summary. When enabled, Your AI Connector automatically generates a conversation summary for the contact when one of those tags is applied, and includes it in the webhook data — full context without a separate request.

Testing Your Webhook #

1. Open Settings → Integrations → Webhooks.
2. On your webhook’s row, click Test.
3. Check your external system to confirm it received the test data.
4. Review the data format to make sure your system can parse it correctly.

For a full end-to-end test, send a message that would trigger one of your configured events (a broadcast, or an incoming message on a connected channel) and verify the webhook fires with the real data.

What Counts as a Successful Delivery #

Whether you click Test or the event fires for real, we send the same thing:

• A POST request (never GET), with the body as JSON and Content-Type: application/json.
• The headers listed under Signed Payloads. Signature headers are only included once you’ve set a signing secret.

We treat the delivery as successful when:

• Your endpoint answers with any 2xx status (200, 201, 204 — all fine).
• It answers within 30 seconds.

A few things that surprise people:

• The response body is ignored. You don’t need to return any particular JSON. An empty 200 is enough.
• Redirects count as a failure. We don’t follow them, so a 301 or 302 (including a trailing-slash redirect, or http to https) is recorded as a failed delivery. Save the final URL, not one that redirects.
• Query strings are fully supported. https://your-app.com/hook?token=abc123 is sent exactly as you saved it, so putting a token in the query string works just as well as putting it in the path.
• Your URL must be https:// and publicly reachable. Addresses that belong to Your AI Connector's own infrastructure are rejected, but your own endpoints on Google Cloud Functions, Cloud Run, App Engine, Firebase Hosting or anywhere else are fine.
• A firewall or bot-protection layer in front of your endpoint can block us. The most common case is Cloudflare: if your zone has Bot Fight Mode or a managed challenge on, our request gets a “Just a moment…” challenge page with a 403 instead of reaching your server — and a server-to-server request can never pass a browser challenge, so both the Test button and real events fail the same way. The Test button will tell you when this is happening (“Cloudflare is showing a bot challenge to our request”). Fix it in Cloudflare with a Security / WAF rule that skips challenges for your webhook path (or for the Webhook-Delivery/1.0 user agent), then click Test again.
• If your firewall needs an IP allowlist instead (for example Cloudflare’s free plan, where plain Bot Fight Mode can’t be skipped by a WAF rule, but an IP Access Rule set to Allow runs before it), we can help: every delivery, whether from the Test button or a live event, is sent from one fixed IPv4 address (no ranges, no IPv6, no rotation). Contact support and we will give you the address to allowlist. Keep signature verification as your actual trust check, since it validates every payload regardless of where it came from.
• The Test result tells you exactly what your endpoint answered. A failed test now shows the real reason (the HTTP status your endpoint returned, a timeout, or that we couldn’t reach the address at all) instead of a generic error, and a test on a saved webhook is sent signed when signing is on, exactly like a live event.

Using n8n, Make, or Zapier (“Test URL” vs “Production URL”) #

Automation platforms usually give you two different webhook addresses, and this trips people up:

• A Test URL (in n8n it contains /webhook-test/). This only receives data while you’re actively watching the canvas and have just clicked Listen for test event (or Test workflow). It captures a single event and then stops listening — so clicking Test in Your AI Connector several times in a row only catches the first one, and only if the listen window is active at that exact moment. To test: click Listen for test event in n8n first, then come back to Your AI Connector and click Test once.
• A Production URL (in n8n it contains /webhook/, no -test). This is the one to paste into Your AI Connector for live events. It only works once your workflow is switched Active. If the workflow isn’t active, n8n rejects the request with a “404 / webhook not registered” error, even though Your AI Connector sent the data correctly.

In short: test with the Test URL while listening, but for the webhook to keep working on real contacts, save the Production URL in Your AI Connector and make sure the workflow is Active.

Webhook Data Format #

When a webhook fires, Your AI Connector sends structured data (JSON) to your webhook URL. If you’re using an automation platform like Zapier or Make, it parses this data for you automatically. If you’re building a custom integration:

{
  "event": "contactCreated",
  "contact": { "id": "<contact-id>", "first_name": "Jane", "...": "..." },
  "campaign": { "id": "<campaign-id>", "name": "AI Receptionist", "status": "Live" },
  "agent": { "id": "<agent-id>", "name": "Front Desk" },
  "user": { "id": "<account-id>", "email": "owner@example.com" }
}

campaign or agent — usually one, not both. If your account uses agents, your contacts sit with an agent rather than a campaign, so campaign arrives as null and agent tells you which one handled it. Older campaign-based accounts see the reverse. Read whichever one is filled in; don’t assume campaign is always there.

The agent block arrived on 15 August 2026. It sits alongside campaign on the events tied to a conversation — a concluded chat, do-not-disturb, a resume, an unarchive, an AI pause, a new message, a conversation summary, and the webhook you can set on a tag — and carries the handling agent’s id and name, or null when no agent is involved. It is purely additive: every field you already receive is unchanged, so a receiver you built before that date keeps working with nothing to update.

Some events add their own extra top-level block. For example, Appointment Booked adds an appointment block (see Appointment Booked Webhook), New Message adds a full message block with the text (see New Message Webhook), and Deliveries and Reads add a short message block with just the message’s ID and status (see Deliveries and Reads Webhook).

Deliveries and Reads tell you which message, but not what it said. They carry a message block containing the message’s id and status — and that id is the same messageId the send message endpoint hands back, so you can match a delivery or read receipt to the exact message you sent — but no message body. Replies carries no message block at all. If you need the words that were sent or received, subscribe to New Message alongside them.

Two things to know before you write your receiver. There’s no timestamp field, and no data wrapper. Every block sits at the top level of the JSON object, as shown above.

The 22 Webhook Events #

The 22 webhook events, with the display label you tick in the app and the event code sent in the payload. The event code is a short string that does not match the display label, so match your receiver on the code, not the label:

Two more codes never appear in that list because you don’t subscribe to them: contact_tags_updated, sent by a webhook URL set on an individual tag, and summary_generated, sent when a chat summary is written for a tag in a webhook’s subscribed_to_tags list.

Channel Connected is not sent yet. It appears in the events list, but nothing emits it today. Don’t build against it.

Tag-based and task notifications use their own separate shapes. See Contact Tags Updated and Task Completed.

Contact Created Webhook #

Sent when the Contact Created event fires (a new contact is added manually, via import, or via API).

Event name #

contactCreated

Payload format #

{
  "event": "contactCreated",
  "contact": {
    "id": "<contact-id>",
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith",
    "human_alerted": false,
    "human_alert_reason": null,
    "is_bot_active": true,
    "ad_referral": null
  },
  "campaign": {
    "id": "<campaign-id>",
    "name": "AI Receptionist",
    "status": "Live"
  },
  "agent": {
    "id": "<agent-id>",
    "name": "Front Desk"
  },
  "user": {
    "id": "<account-id>",
    "email": "owner@example.com",
    "first_name": "Alex",
    "last_name": "Doe"
  }
}

The “Test” sample and a real event look slightly different. The test button sends placeholder data (John Doe, a sample campaign). A real Contact Created event carries the actual contact’s details, and some fields may be empty depending on the channel.

New Message Webhook #

This webhook fires every time a message is added to a conversation, on any channel. It covers both directions: messages your contact sends you, and messages your AI, your team, or a campaign sends them. It is the only webhook that includes the message text, so it is the one to use when you want to mirror conversations into an external system.

Event name #

new_message

Payload format #

{
  "event": "new_message",
  "contact": {
    "id": "<contact-id>",
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith",
    "human_alerted": false,
    "human_alert_reason": null,
    "is_bot_active": true,
    "ad_referral": null
  },
  "agent": {
    "id": "<agent-id>",
    "name": "Front Desk"
  },
  "user": {
    "id": "<account-id>",
    "email": "owner@example.com",
    "first_name": "Alex",
    "last_name": "Doe"
  },
  "message": {
    "id": "<message-id>",
    "body": "Hi, are you open on Saturday?",
    "direction": "inbound",
    "status": "received",
    "created_at": "2026-07-30T17:27:06.000Z",
    "channel": "whatsapp_web"
  }
}

There is still no campaign block in this payload. New Message sends contact, agent, user and message. The agent block was added on 15 August 2026 and tells you which agent handles the conversation; if you need campaign context as well, look the contact up through the API using contact.id.

Internal AI records do not fire this webhook. Alongside real messages, the platform keeps its own bookkeeping rows in a conversation (the AI’s tool calls and internal turn records). Those are never sent — you only receive messages that were genuinely sent or received.

Deliveries and Reads Webhook #

These two events report what happened to a message after it left Your AI Connector: Deliveries fires when a message reaches the contact (or fails to), and Reads fires when the contact opens it, on the channels that support read receipts.

Both carry a message block with the ID of the message the event is about, so you can match the update to the exact message you sent.

Event names #

delivered and undelivered for Deliveries, read for Reads.

Payload format #

{
  "event": "delivered",
  "contact": {
    "id": "<contact-id>",
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith",
    "ad_referral": null
  },
  "campaign": {
    "id": "<campaign-id>",
    "name": "AI Receptionist",
    "status": "Live"
  },
  "agent": {
    "id": "<agent-id>",
    "name": "Front Desk"
  },
  "user": {
    "id": "<account-id>",
    "email": "owner@example.com",
    "first_name": "Alex",
    "last_name": "Doe"
  },
  "message": {
    "id": "<message-id>",
    "status": "delivered"
  }
}

How to match an update to the message you sent. Store the messageId you get back when you send a message through the API. When a Deliveries or Reads notification arrives, look up that stored ID against message.id in the payload — that’s your delivery or read receipt for that exact message.

There is no message text here. The message block carries only the ID and the status. Subscribe to New Message if you also need the body.

The message block is only present when we know which message it was. On the rare update we can’t tie back to a stored message, the block is left out entirely rather than sent empty — so check that message exists before reading message.id.

One notification per status change. A single outgoing message normally produces a delivered notification and then, on channels with read receipts, a read one. A failed send produces undelivered instead.

Appointment Booked Webhook #

Fires when a contact books an appointment. It fires the same way whether the AI booked it during a conversation, you booked it by hand, or it came in through the API.

Event name #

booked

Payload format #

{
  "event": "booked",
  "contact": {
    "id": "<contact-id>",
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith"
  },
  "campaign": {
    "id": "<campaign-id>",
    "name": "AI Receptionist",
    "status": "Live"
  },
  "user": {
    "id": "<account-id>",
    "email": "owner@example.com"
  },
  "appointment": {
    "appointment_id": "<appointment-id>",
    "start_time": "2026-07-20T15:00:00.000Z",
    "end_time": "2026-07-20T15:30:00.000Z",
    "status": "confirmed",
    "room_name": "Room 1",
    "description": "Discovery call",
    "summary": "30 min intro",
    "google_calendar_event_id": null,
    "event": {
      "id": "<service-id>",
      "event_name": "Intro Call",
      "slot_duration": 30,
      "location": "Zoom",
      "meeting_link": "https://...",
      "event_type": "online"
    }
  }
}

google_calendar_event_id is often null in this webhook, and that is normal. The Google Calendar event is created at the same moment this notification goes out, so the ID usually isn’t ready yet. Re-fetch the appointment by its appointment_id a moment later if you need it. It stays null permanently if the account has no Google Calendar connected, so don’t wait on it forever.

The “Test” button does not include the appointment block. Use it to confirm your endpoint answers, then make one real booking to see the full payload.

Two cases where this webhook does not fire: appointments imported from an external calendar, and bookings that come in through the Formitable integration.

Contact Tags Updated Webhook #

Fires when a tag is applied to a contact, and that tag has a webhook URL configured on the agent or campaign the contact belongs to.

Event name #

contact_tags_updated

When it fires #

• A tag is applied to a contact that has an agent assigned, a campaign assigned, or both.
• At least one of the applied tags has a webhook URL set in the Tags tab of that agent or campaign.

If the contact has both and the campaign’s tags carry webhook URLs, those win; the agent’s are used otherwise.

If multiple tags with different webhook URLs are applied in the same update, one request is sent per URL, each containing only the tags that map to that URL.

Removing a tag never sends a request. Most people point these URLs at an action — collect a deposit, book a slot, alert a rep — so a tag coming back off a contact used to re-run that action. It no longer can. A removal still shows up in removed_tags when it happens in the same update as an apply that goes to the same URL, so an automation that reads both arrays keeps the full picture; what it will never see is a request caused by a removal alone. (Changed August 12, 2026. Before that date, removals sent a request too.)

Payload format #

{
  "event": "contact_tags_updated",
  "contact": {
    "id": "<contact-id>",
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith",
    "human_alerted": false,
    "is_bot_active": true,
    "ad_referral": {
      "ctwa_clid": "ARAbc123...",
      "source_id": "120210000000000",
      "source_type": "ad",
      "source_url": "https://fb.me/xxxx",
      "headline": "Get 20% off today",
      "body": "Message us now to claim your discount",
      "channel": "whatsapp"
    }
  },
  "added_tags": ["qualified-lead"],
  "removed_tags": ["new-lead"],
  "agent": {
    "id": "<agent-id>",
    "name": "Front Desk"
  },
  "user": {
    "email": "owner@example.com",
    "first_name": "Alex",
    "last_name": "Doe"
  }
}

Testing a tag webhook #

Next to the webhook URL field on the Tags tab there is a Test button. It sends a sample payload to that URL immediately, so you can confirm your automation receives it before waiting on a real conversation.

The test sends the same contact_tags_updated shape shown above, using a placeholder contact, with the tag you are testing in added_tags and an empty removed_tags. What your automation sees in the test is what it will see in production.

Two things to know:

• Save the tag first. The test looks the tag up by its saved name, so a brand new tag or an unsaved rename can’t be tested yet. The button stays greyed out until the name on screen matches the saved one.
• A failed test doesn’t count against your webhook. Tests never contribute to the automatic switch-off after repeated failures described in Webhook Reliability.

If the test fails, the message tells you what your endpoint answered (for example a 404 or 500), which is usually enough to spot a wrong URL or a workflow that isn’t switched on.

Task Completed Webhook #

For reference only. Task webhooks (as data) are documented here for developers; the Task Created, Task Updated and Task Completed events are selectable in the standard events list on the webhook form like any other event — see Available Trigger Events and The 22 Webhook Events.

This payload is sent when a task transitions into a stage marked as a completion stage. A task moving between non-completion stages sends the taskUpdated shape instead.

Event name #

taskCompleted

When it fires #

• A task is updated.
• Its stage value changed compared to its previous value.
• The new stage is configured as a completion stage on the account’s task stage settings.

Payload format #

{
  "event": "taskCompleted",
  "contact": {
    "email": "jane@example.com",
    "phone_number": "+15551234567",
    "first_name": "Jane",
    "last_name": "Smith",
    "human_alerted": false,
    "human_alert_reason": null
  },
  "user": {
    "email": "owner@example.com",
    "first_name": "Alex",
    "last_name": "Doe"
  },
  "message": {
    "id": "<task-id>",
    "title": "Follow up with Jane",
    "description": "Confirm pricing and send proposal",
    "type": "follow_up",
    "priority": "high",
    "stage": "<stage-id>",
    "due_date": "2026-01-20T15:00:00Z",
    "source": "ai",
    "source_detail": "<source-detail>",
    "campaign_id": "<campaign-id>",
    "linked_human_alert": "<human-alert-id>",
    "tags": ["qualified-lead"],
    "notes": "Customer requested a callback"
  }
}

Switching a Webhook Off (or Deleting It) #

Every webhook has an on/off switch, right on its row. Switching one off stops it receiving events, but keeps everything you configured — the URL, the events, any signing secret. Switch it back on and it picks up where it left off; nothing that happened while it was off is delivered afterwards.

Use it when you want deliveries to stop for a while: your endpoint is being rebuilt, you’re debugging a noisy integration, or you’re pausing an automation.

Deleting a webhook (the trash icon on its row) removes it for good, including its signing secret. If you only want deliveries to stop, switch it off instead — delete is for when you’re done with the endpoint entirely.

This is not the same as a webhook being switched off automatically. If we disable your webhook after repeated failures (see Webhook Reliability), the toggle above won’t bring it back. Once your endpoint is fixed, edit the webhook and save it with a changed URL (any URL change re-enables it), or call the re-enable endpoint over the API — or ask support and we’ll flip it back for you.

Signed Payloads (Verifying a Webhook Really Came From Us) #

Anyone who learns your webhook URL could send a fake request to it. If you act on webhooks automatically — updating billing, creating CRM records — turning on signing lets you verify each request genuinely came from us.

Signing is optional and off by default, and you switch it on per webhook, from that webhook’s edit view (open a saved webhook’s row).

Turning on signing #

1. Open the webhook (Settings → Integrations → Webhooks → click your webhook’s row).
2. In the Signing secret section, click Generate.
3. Copy the secret (it starts with whsec_) and store it in your receiving system. Treat it like a password.

You can come back and reveal, copy, rotate, or turn off the secret any time from this same panel.

What we send #

Once signing is on, every delivery for that webhook carries these two extra HTTP headers:

These three are on every delivery, signed or not:

How to verify #

The signature is an HMAC-SHA256 of the string <timestamp>.<raw request body>, using your signing secret as the key.

Verify against the raw request body — the exact bytes you received. If your framework parses the JSON and re-serializes it before checking, the bytes can change and the signature won’t match.

Node.js example:

const crypto = require("crypto");

function verify(rawBody, headers, secret) {
  const timestamp = headers["x-webhook-timestamp"];
  const signature = headers["x-webhook-signature"]; // "v1=<hex>"

  // Reject anything older than 5 minutes so a captured request can't be replayed later.
  if (Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) return false;

  const expected = crypto.createHmac("sha256", secret).update(`${timestamp}.${rawBody}`).digest("hex");

  return crypto.timingSafeEqual(Buffer.from(signature.replace("v1=", "")), Buffer.from(expected));
}

Python example:

import hashlib, hmac, time

def verify(raw_body: bytes, headers, secret: str) -> bool:
    timestamp = headers["X-Webhook-Timestamp"]
    signature = headers["X-Webhook-Signature"].replace("v1=", "")

    # Reject anything older than 5 minutes so a captured request can't be replayed later.
    if abs(time.time() - int(timestamp)) > 300:
        return False

    expected = hmac.new(secret.encode(), f"{timestamp}.".encode() + raw_body, hashlib.sha256).hexdigest()

    return hmac.compare_digest(signature, expected)

Compare signatures with a timing-safe function (timingSafeEqual / compare_digest), not ==. It costs nothing and avoids a subtle class of attack.

Rotating the secret #

Click Rotate to replace the secret. The switch is immediate: the very next delivery is signed with the new secret only. If your endpoint is live, accept both the old and the new secret for a few minutes while you deploy the new one.

Turning signing off simply stops the signature headers being sent.

Retrying Failed Deliveries #

By default, a delivery that fails is not retried — if your system is down at that moment, that event is missed.

Turn on Retry failed deliveries on a webhook (in the create/edit form) and we’ll keep trying:

That spans roughly 2 hours and 40 minutes, so a webhook can survive a maintenance window or a short outage on your side.

What gets retried: temporary problems — your server returning a 5xx error, a timeout, or a connection failure.

What does not: if your endpoint rejects the request itself (any 4xx), we don’t retry — sending the identical request again would only produce the identical rejection.

Which events retry: tag webhooks (contact_tags_updated), the three task events, and the daily summary. The rest are sent once, so for those the switch has nothing to act on. Every event still carries X-Webhook-Delivery, so one dedupe rule covers all of them.

Turn on retries only if your endpoint is idempotent. Retries mean the same event can arrive more than once. Use the X-Webhook-Delivery header to recognise a repeat: it stays the same across every attempt for one event, so you can safely ignore an ID you’ve already handled.

Retries interact with the automatic switch-off after repeated failures (see Webhook Reliability) in the way you’d want: the failure counter counts a whole delivery, only after every retry has been used up — not each individual attempt.

Webhook Reliability #

• Your AI Connector sends webhooks over a secure connection (HTTPS). Make sure the web address you provide uses HTTPS.
• If your system returns an error, the delivery is considered failed.
• Monitor your receiving system’s uptime to avoid missing events.
• For critical workflows, turn on Retrying Failed Deliveries, and consider a fallback mechanism as well.

Webhooks are switched off automatically after repeated failures. If your webhook URL fails repeatedly (about 5 errors in a row, or 3 in a row for configuration-type errors), Your AI Connector automatically stops sending events to that URL. To bring it back once your endpoint is healthy: edit the webhook and save it with a changed URL (any URL change re-enables it), or use the re-enable endpoint over the API — re-saving with the same URL is not enough. Support can also re-enable it for you.

Troubleshooting #

Next Steps #

• GoHighLevel Integration — use webhooks to integrate Your AI Connector with GHL.
• API Access — combine webhooks with the API for powerful automations.
• Using Tags to Label Contacts — set up tags that trigger your webhooks.