Skip to main content
Webhooks let Botdog push events to your own HTTP endpoint as they happen, so you can sync activity into your CRM, trigger downstream automations, or build internal dashboards without polling the API. When a campaign performs an action — visiting a lead’s profile, sending an invitation, receiving a reply — Botdog POSTs a JSON payload to the URL you configured. Each request is signed so you can verify it really came from Botdog.

​
When to use webhooks

​
How it works

  1. You create a webhook in the Botdog dashboard at Settings → Integrations → Webhooks. You pick an endpoint URL, a scope, and the events you want. Scope comes first, because it decides which events a webhook can carry: ALL and SPECIFIC_CAMPAIGNS carry campaign events, while CONNECTED_ACCOUNT carries events that belong to no campaign, such as NON_CAMPAIGN_LEAD_INBOX_MESSAGE_RECEIVED. The two sets are disjoint, so to receive both, create two webhooks pointing at the same URL.
  2. Botdog generates a secret and shows it to you once. Store it — you’ll use it to verify signatures.
  3. When a subscribed event happens, Botdog POSTs a signed JSON body to your endpoint.
  4. Your endpoint responds with any 2xx status code to acknowledge receipt. Anything else is treated as a failure and retried.

​
Request format

Every delivery is an HTTP POST with:
  • Header Content-Type — application/json
  • Header X-Webhook-Signature — t=<timestamp>,s=<HMAC-SHA256 of "{t}.{rawBody}">. The timestamp is part of what is signed, not just the body. See Signature verification.
  • Body — a JSON object whose shape depends on the event. Lead events carry the contact’s identity, profile (job title, location, headline and more), any contact details Botdog holds, and the lead fields you imported — including your own custom columns. See Events and payloads.

​
Responding to a delivery

  • Reply with 2xx quickly — ideally under a few seconds. Do the heavy work asynchronously after acknowledging.
  • Treat deliveries as at-least-once — Botdog retries on failure, so your handler should be idempotent. Use the top-level id field to deduplicate.
  • Non-2xx responses are retried with exponential backoff. See Delivery and retries.

​
Managing webhooks

Webhooks are created and managed from the dashboard at Settings → Integrations → Webhooks. From there you can:
  • Create a webhook with a name, endpoint URL, event subscriptions, and scope.
  • Pause or resume a webhook without deleting it.
  • Send a test event to verify your endpoint receives and validates the request.
  • Inspect recent deliveries, including status code, response body, and retry attempts.
  • Rotate the secret if it may have been exposed.

​
Slack channels

A webhook’s destination can be a Slack channel instead of a generic HTTP endpoint. When you select Slack channel as the destination type, Botdog formats every event as a clean Slack message — including the contact’s name, company, campaign, and a button to open their LinkedIn profile — rather than posting a raw JSON body. Setting it up: In Slack, open your workspace’s app directory, add the Incoming Webhooks app, click Add New Webhook to Workspace, and choose the channel you want. Copy the https://hooks.slack.com/services/… URL it gives you, then in the Botdog webhook form choose Slack channel as the destination and paste it in. Note: signature verification does not apply to Slack destinations. Slack doesn’t use the signing secret — the webhook URL itself is the secret, so keep it private.

​
Next steps