Beton + Webhooks

When the destination doesn't exist as a native integration

Beton has native integrations for the most common revenue destinations — Attio, HubSpot, Apollo, Pipedrive, Zoho — but the long tail of internal tools, custom dashboards, Slack alerting systems, ticketing platforms, and home-grown CRMs is enormous. Webhooks are the answer. Any HTTPS endpoint that can accept a POST body becomes a Beton signal destination, with no integration code on Beton's side.

The webhook destination ships every fired signal as a JSON payload to the URL you configure, with the signal type, confidence score, the relevant person/account references, and the underlying event IDs that triggered it. From your endpoint, you can do whatever your stack does — open a Pipedrive deal, post to a Slack channel, file a ticket in Linear, kick off a workflow in n8n, route to your own internal alerts service.

Common destinations teams build against the webhook

• Slack channels for live signal alerts — a #revenue-signals channel where the AE on duty sees high-confidence signals as they fire, with a link back to the contact or account.
• Internal CRMs and homegrown deal trackers that don't have public APIs Beton supports natively — the team writes a thin handler that maps the Beton payload to their internal schema and applies it.
• n8n, Zapier, or Make workflows for teams already orchestrating cross-tool automation — Beton becomes one more event source in the existing automation graph.
• Customer.io, Braze, or other lifecycle-marketing platforms when the team wants product signals to drive in-app messages or email lifecycle flows in addition to outbound.
• Salesforce via a thin webhook bridge — for teams that haven't yet adopted a native Beton-supported destination but want signals in Salesforce today, a one-page handler running on Vercel or Cloudflare Workers gets it done.
• PagerDuty or Opsgenie for high-severity signals like sudden churn risk on enterprise accounts, where a paging-style alert is the right escalation path.

Payload shape and reliability

Every Beton webhook delivery is signed with an HMAC header derived from a shared secret, so your endpoint can verify the request came from Beton rather than from somewhere else. Retries follow exponential backoff on 5xx responses; 4xx responses are treated as permanent failures and logged for visibility. The signal payload is stable across releases — schema versioning is explicit, so handlers don't break silently when Beton ships a new field.

Multi-destination routing

The same signal can fire to multiple webhook destinations simultaneously, with optional per-destination filtering on signal type or confidence threshold. A high-confidence churn signal might go to both your CRM (full payload) and a Slack channel (one-line summary) and a PagerDuty endpoint (only when the affected account is on the enterprise plan). Beton handles the fan-out; your endpoints handle their own concerns.

When to reach for the webhook vs. wait for native

If the destination you need is on Beton's native integration list, use the native integration — it handles deduplication, retry, and idempotency in ways that custom handlers usually don't. If the destination isn't native, the webhook is the right answer, and most teams have a working signal flow into a custom destination within an hour of pointing the webhook at their endpoint. Native integrations roll out periodically; the webhook is the bridge until the one you need ships.