agentsclimarketplace

Webhooks

Skill linkrunner-labs/skills/skills/integrations/webhooks

Installable Agent Skills for integrating the Linkrunner SDK and deep linking, for AI coding agents (Claude Code, Cursor, Windsurf, Copilot)

Install
npx -y skills add linkrunner-labs/skills --skill webhooks

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 16 days oldThe repository was created 16 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Set up a Linkrunner webhook receiver in a backend app to get real-time install and signup attribution events - detect the backend framework (Express, Fastify, Next.js API routes, NestJS, Flask, FastAPI, Django, etc.), add a route that verifies the linkrunner-key header, and handle the payload idempotently. Use when someone asks to set up Linkrunner webhooks, receive install/signup webhooks, or handle a Linkrunner webhook in their backend.

SKILL.md

4.1 KB, 910 tokens by cl100k_base, as published. Nobody here has run it

Linkrunner - Webhooks integration

You are adding a server-side webhook receiver for Linkrunner attribution events to a backend project. Linkrunner sends a POST request to a URL you configure in the dashboard whenever an install is attributed or a user signs up. Work in this order and inspect the project before editing - do not paste snippets blindly.

0. Before you touch anything

  1. Detect the backend framework and language: package.json for express / fastify / next / @nestjs/core; requirements.txt or pyproject.toml for flask / fastapi / django; adjust for anything else you find. Do not assume - read the manifest.
  2. Find where routes/handlers already live (an existing routes/, api/, or controllers/ tree; for Next.js, app/api/*/route.ts or pages/api/*.ts; for Django, urls.py) and add the webhook route there, matching the project's existing conventions (routing style, error handling, logging).
  3. Find how secrets are configured (.env, a config module, a secrets manager) - the project's private key belongs there, never hardcoded.
  4. Get the project's private key from the dashboard (Settings -> Webhooks) if it isn't already in the project's env as something like LINKRUNNER_PRIVATE_KEY.

1. Decide what the user actually needs

They want...Do this
"Set up Linkrunner webhooks" / "receive install/signup events"references/setup.md (dashboard config + payload) then references/handler.md (write the receiver)
"Verify my endpoint works"scripts/verify-webhook.sh
"Not receiving webhooks" / "getting 401s"Re-check header verification in references/handler.md; troubleshooting notes in references/setup.md

2. Golden rules

  • Verify the linkrunner-key header against the stored private key before processing anything, using a constant-time compare. This is the only authentication Linkrunner webhooks use - there is no HMAC signature scheme, so don't invent one.
  • Respond with a 2xx status as fast as possible (well under the 5s Linkrunner expects). Acknowledge first, then do the real work asynchronously (queue, background job, setImmediate/background task) - Linkrunner does not wait for your processing to finish.
  • Make handling idempotent: dedupe on event_type + campaign_id + user_id (when present) + a device id (gaid/idfa) or timestamp. Linkrunner retries up to 3 times (immediate, +1s, +2s) on any non-2xx response, so the same event can arrive more than once.
  • Branch on event_type ("install" | "signup") - never assume every payload has a user_id. Identity fields (user_id, name, phone, email) only arrive on signup; install gives you device ids (gaid/idfa) to match against the later signup.
  • Log failures and alert on repeated ones - after 3 failed attempts Linkrunner stops retrying and marks the webhook failed.

3. Finish

After writing the handler, run scripts/verify-webhook.sh <url> <linkrunner-key> to POST a sample install and signup payload and confirm both return 2xx. Report which checks passed, and remind the user to:

  • paste the endpoint URL into the dashboard (Settings -> Webhooks)
  • confirm the key used in the handler matches the private key shown there

References

  • references/setup.md - dashboard config, events and when they fire, headers, full payload field list
  • references/handler.md - idiomatic receiver implementations (Express, FastAPI, Flask) with verification, idempotency, and async processing

Gives 0 of the 12 instructions most apis services skills give in 910 tokens

Counted across 424 of the 426 authors here whose files we hold, read 2026-08-06

  • use plural nouns for resource namesin 41 of 424, across 32 files
  • use cursor-based pagination for large datasetsin 35 of 424, across 20 files
  • include rate limit headers in responsesin 25 of 424, across 13 files
  • Use kebab-case for multi-word resourcesin 23 of 424, across 13 files
  • version APIs in the URL pathin 19 of 424, across 9 files
  • use semantic HTTP status codesin 18 of 424, across 8 files
  • verify webhook signaturesin 18 of 424, across 11 files
  • use query parameters for filteringin 17 of 424, across 6 files
  • use async database operationsin 14 of 424, across 7 files
  • wrap successful responses in a data fieldin 13 of 424, across 3 files
  • prefix sorting parameters with a hyphen for descending orderin 13 of 424, across 3 files
  • set appropriate HTTP status codesin 13 of 424, across 6 files

Said here and by no other author read

  • inspect the project before editing
  • read the manifest to detect the backend framework
  • match existing routing conventions when adding the route
  • store the private key in the project secrets manager
  • verify the linkrunner-key header using constant-time compare
  • branch handling on event type

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.