How webhooks work
A webhook is a push notification between servers. You give a service a URL. When a chosen event happens, the service sends an HTTP POST to that URL with a JSON body describing the event. Your server reads it and does something: writes a row, updates a CRM record, posts to Slack.
A worked example: a user taps a Meta ad, installs the app and signs up. Seconds later your backend receives a sign-up webhook with the user ID, campaign, ad set, creative and network. Your CRM tags the user with their acquisition source before the welcome email goes out, so onboarding can differ for users from a referral campaign versus a discount campaign.
Webhooks versus APIs and exports
- Webhook (push): real time, one event per request, no polling. You need an endpoint that is always up.
- API (pull): you query when you need data. Good for dashboards, lookups and backfills.
- Export: a batch file for a period. Good for analysis and reconciliation.
Most teams use webhooks for real-time workflows and an API or export to fill any gaps.
Building a reliable receiver
- Verify the sender. Check the secret or signature header on every request.
- Respond fast. Return a 2xx status quickly and process the payload in a background job.
- Be idempotent. Retries can deliver the same event twice, so key writes on a unique ID.
- Allowlist IPs when the sender publishes static addresses.
- Log and alert. Track failures so you notice before data goes missing.
Webhooks in Linkrunner
Linkrunner sends webhooks for install and sign-up events with attribution data, with organic installs as an opt-in. Requests carry a linkrunner-key header for verification, come from static IPs, and get up to 3 delivery attempts. Webhooks can also be formatted for Slack. Webhooks for every event are built on request. Webhooks are on every plan, and Linkrunner's Agent Skills can generate a receiver for your backend (npx @linkrunner/skills add webhooks). See APIs and webhooks.