Skip to main content

Overview

Webhooks allow you to receive real-time HTTP notifications when attribution events occur in your app. When a user installs your app or signs up, Linkrunner sends a POST request to your configured endpoint with detailed attribution data. Common use cases:
  • Server-side analytics and reporting
  • CRM integration for user onboarding
  • Real-time Slack notifications
  • Custom attribution pipelines

Configuration

Setting Up Your Webhook URL

  1. Go to Linkrunner Settings → Webhooks
  2. Enter your webhook endpoint URL
  3. Save the configuration
Your endpoint must be publicly accessible and respond with a 2xx status code to acknowledge receipt.

Testing Your Endpoint

Before going live, verify your endpoint can:
  1. Accept POST requests with JSON body
  2. Respond within a reasonable time (recommended under 5 seconds)
  3. Return a 2xx status code on success

Webhook Events

Linkrunner sends webhooks for the following events:

Install Webhook

The install webhook is triggered immediately when Linkrunner attributes an app installation. At this point, your app has just been opened for the first time and the user hasn’t had a chance to sign up or log in yet. Because of this, user identity fields such as user_id, name, phone, email, and additional_data are only included in signup webhooks. However, the install webhook does include device identifiers (gaid for Android, idfa for iOS) when available. You can use these to match the install with the user later when they sign up. Use the install webhook for:
  • Tracking install counts by campaign
  • Analyzing attribution data (network, ad creative, etc.)
  • Monitoring app store conversion rates
  • Storing device IDs to link with user accounts later

Signup Webhook

The signup webhook is triggered when you call the .signup() method in your app via the Linkrunner SDK. This happens after the user has signed up or logged in, so the user_id field will contain the ID you passed to the SDK. The signup webhook includes device identifiers (gaid/idfa) along with the user_id, giving you a complete picture of both the device and the user. It also includes user identity fields (name, phone, email) and any custom parameters you passed via additional_data, such as referral codes or other custom key-value pairs. Use the signup webhook for:
  • Linking attribution data to your user records
  • CRM integration and user onboarding flows
  • Calculating signup conversion rates from installs
  • Forwarding custom parameters (e.g., referral codes) to your backend
To receive signup webhooks, you must call .signup() in your app after the user signs up or logs in. See your SDK’s usage guide for implementation details.

Payload Structure

All webhooks are sent as POST requests with a JSON body.

Headers

Body Parameters

The name, phone, and email fields are populated from user_data passed to the SDK’s .signup() or .trigger() methods.
The additional_data field is populated from the SDK data object.
Fields that are not available can be null or omitted from the payload.

Meta Campaign Details

When the attribution is from Meta Ads, meta_campaign_details contains:

Google Campaign Details

When the attribution is from Google Ads, google_campaign_details contains:

Apple Search Ads Details

When the attribution is from Apple Search Ads, apple_search_ads_details contains:

Campaign Details

For supported non-Meta and non-Google ad networks, campaign_details contains:

Additional Data

The additional_data object contains custom parameters and device data passed through the SDK. This is useful for forwarding arbitrary key-value pairs like referral codes or custom identifiers through the attribution flow. Example:

Example Payloads

Install Event

Signup Event

Authentication

Every webhook request includes a linkrunner-key header containing your project’s private key. Use this to verify that requests are genuinely from Linkrunner.
Never expose your private key in client-side code. Store it securely as an environment variable.

Slack Integration

Linkrunner automatically formats webhook payloads for Slack when your URL contains hooks.slack.com. Instead of raw JSON, Slack receives a rich Block Kit formatted message displaying:
  • Event type and user ID
  • App version and network
  • Campaign name
  • Attribution timestamps
  • Device identifiers (GAID/IDFA)
  • User identity (name, phone, email)
  • Meta, Google, Apple Search Ads, or generic campaign details, when available
To set up Slack notifications:
  1. Create an Incoming Webhook in your Slack workspace
  2. Copy the webhook URL (format: https://hooks.slack.com/services/...)
  3. Paste it as your webhook URL in Linkrunner settings

Retry Behavior

If your endpoint fails to respond with a 2xx status code, Linkrunner makes up to 3 attempts total with exponential backoff: After 3 failed attempts, the webhook is marked as failed. Ensure your endpoint is reliable to avoid missing events.

Best Practices

1

Respond quickly

Return a 2xx status code as fast as possible. Process the webhook data asynchronously to avoid timeouts.
2

Implement idempotency

Store processed webhook events using event_type, campaign_id, user_id when present, and the relevant device identifier or timestamp.
3

Validate authentication

Always verify the linkrunner-key header matches your private key before processing.
4

Handle failures gracefully

Log failed webhook processing for debugging and implement alerting for critical failures.

Troubleshooting

Webhooks not being received?
  • Verify your endpoint URL is correct and publicly accessible
  • Check that your server accepts POST requests with JSON body
  • Ensure your firewall allows incoming requests from Linkrunner
Getting 401 errors?
  • Verify the linkrunner-key header validation in your code
  • Check your private key matches the one in your dashboard settings
Missing data in payload?
  • name, phone, and email require you to pass user_data to the SDK’s .signup() or .trigger() methods
  • user_id requires SDK configuration to be passed
  • Device identifiers (gaid/idfa) depend on user consent and SDK implementation
  • additional_data requires passing a data object to the SDK and contains those custom parameters
  • Network-specific detail objects are only populated when that network provided attribution data
Need help? Contact support@linkrunner.io