Webhooks

When a conversion fires in Routy, you usually want something to happen somewhere else. Push the conversion back to Google Ads as a conversions-API event so Smart Bidding sees it. Send the same conversion to Meta's CAPI. Sync the lead into your CRM. Trigger an internal workflow that updates a customer record, sends an internal Slack message, or starts a downstream automation. Webhooks are the generic mechanism for all of that — Routy fires an HTTP request to your endpoint on every conversion, with the data formatted exactly the way you specify.

The webhook system is built around the reality that every receiving system wants a different format. Google Ads expects one set of fields, Meta expects another, your CRM expects a JSON payload with specific keys, your internal API expects URL-encoded form data. The webhook configuration lets you define the request shape per scope — per traffic source for ad-network postbacks, per-affiliate for catch-all sync — so each downstream system gets the format it actually expects.

After setting up webhooks, the following becomes available:

• Real-time HTTP notifications on every conversion event. The request fires within milliseconds of the conversion being recorded. GET or POST methods, your endpoint, your format.
• Per-traffic-source webhooks for ad-network postbacks. One webhook per source means each platform (Google Ads, Meta, Microsoft Ads, TikTok) gets exactly the format and parameter mapping it expects. The Google Ads webhook can use the GCLID-based conversion upload format; the Meta webhook can fire to the CAPI endpoint with hashed user data; the TikTok webhook hits the Events API with its event-name conventions.
• Affiliate-level webhooks that fire on every conversion regardless of source. Useful for central CRM sync, internal pipelines, or partner notifications where the receiving system needs every conversion event without per-source segmentation.
• Template variables in the URL and body. {{clickId}}, {{eventName}}, {{conversionAmount}}, {{currency}}, {{trafficSource}}, and others can be dropped anywhere they belong in the request. The template substitution happens at fire time, so each request carries the right values for that specific conversion.
• Conversion-type filtering and renaming. Fire the webhook only on first-time deposits if that's the event your downstream system cares about, and map the event name (e.g. "First Time Deposit" → ftd) for the platform that expects a specific identifier rather than free text.
• Simulate before you ship. The webhook configuration includes a test button that fires a sample event to your endpoint, so you can confirm the contract before going live and avoid the "we've been silently failing for two weeks" situation. The test response is shown alongside the configuration.

Up to 5 webhooks per scope, which covers almost every real-world setup — most accounts end up running 2-4 webhooks per traffic source (one for the ad platform's conversion API, one for an internal pipeline, occasionally one for a CRM sync) and 1-2 affiliate-level webhooks.

You add a webhook through the webhooks section of your Routy dashboard. The configuration includes:

• The destination URL, including any template variables for the path and query string
• The scope — affiliate-wide or a specific traffic source
• The HTTP method (GET or POST)
• The body template for POST requests, with template variables for the dynamic fields
• Headers if the receiving system requires authentication or specific content types
• Optional filters — fire only on specific event types, only over a specific conversion amount, only for specific traffic sources within the scope

Once configured, the webhook fires on every matching conversion. Routy uses its own retry logic for transient failures (HTTP 5xx, timeouts, network errors) — typically three retries with exponential backoff — and logs every fire attempt with its response status. If the destination is consistently failing, the webhook is automatically paused after a configurable threshold and surfaces in your alerts so you can investigate.

Worth knowing:

• Webhook latency between conversion fire and outbound HTTP request is typically under 500ms.
• The retry logic does not retry HTTP 4xx responses (the destination explicitly rejected the request). 4xx responses are logged but treated as terminal failures, so a permission error or malformed-body error doesn't generate a retry storm.
• Body templates support JSON, form-encoded, or plain-text formats. You write the template; Routy substitutes the variables at fire time.

For paid-traffic operations, the conversion-API webhook is the difference between Smart Bidding learning from your real conversions and Smart Bidding learning from whatever the on-page pixel happened to see. Sending conversions back via the right webhook to Google Ads, Meta, TikTok, and Microsoft Ads gives each platform's bidding algorithm a stream of server-side, deduplicated, attribution-accurate events. Over a few weeks, that almost always shows up as more efficient spend and lower CPA on each platform.

For affiliate operations doing lead-gen or higher-touch sales work, the CRM webhook is the difference between knowing a lead arrived and knowing what to do with it. The webhook can push the lead into HubSpot, Salesforce, or whatever internal CRM you run, with the conversion metadata attached, so the sales team has the context they need without anyone running a daily CSV import.

For internal-pipeline use cases — fraud monitoring, fulfilment automation, partner notifications — the affiliate-level webhook gives every conversion event a place to go, in the format the receiving system expects, fired automatically as the conversion lands.