agentleFS
LeostrukaLeostruka/devin-bundle/skills/webhooks/SKILL.md

webhooks

Skill0 starsChanged 3 months agoMITView on GitHub

Use when building or debugging endpoints that receive third-party callbacks (payments, GitHub, ERP). Webhook receiver discipline - signature verification, idempotency by event id, fast acknowledge with background processing, replay protection.

15 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use data-pipelines, incident-response and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • YepAPISkill

    data-pipelines

    ETL patterns, cron scheduling, queue-based processing, and batch jobs with Inngest/BullMQ.

    Also in 3 projects that use this

  • AnthropicSkill

    incident-response

    Run an incident response workflow — triage, communicate, and write postmortem. Trigger with "we have an incident", "production is down", an alert that needs severity assessment, a status update mid-incident, or when writing a blameless postmortem after resolution.

    Also in 3 projects that use this

  • OpenAISkill

    observability

    Vercel Observability expert guidance — Drains (logs, traces, speed insights, web analytics), Web Analytics, Speed Insights, runtime logs, custom events, OpenTelemetry integration, and monitoring dashboards. Use when instrumenting, debugging, or optimizing application performance and user experience on Vercel.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 12 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    ALWAYS verify the provider signature (payload HMAC with the secret, or the provider's own mechanism).

    line 22
  2. Distinctive:

    Test a real duplicate: send the same event 2x and confirm single effect.

    line 48
  3. Distinctive:

    Test replay/lag: an old event must not corrupt state.

    line 49
  4. Distinctive:

    No event_id: duplicate becomes double effect (2x charge).

    line 55

“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Webhooks

A webhook endpoint is a public endpoint receiving POSTs from third parties: without verified signatures anyone injects events; without idempotency retries duplicate effects.

When to use

  • Creating an endpoint that receives webhooks (payment, GitHub, ERP).
  • Debugging duplicated or lost events.
  • Reviewing an existing callback endpoint.

Hard rules

Event authentication

  • ALWAYS verify the provider signature (payload HMAC with the secret, or the provider's own mechanism). Never trust the payload.
  • Constant-time signature comparison (hash_equals): normal comparison leaks timing.
  • Secret outside the code (secrets/env) with a rotation procedure.

Idempotency and retry

  • Same event_id processed twice = effect once: store processed event_ids (table with unique constraint) and ignore duplicates.
  • Respond 2xx fast (ack) and process later in a queue. Never process synchronously with the provider timeout on your neck.
  • Events arrive out of order: process by state, do not assume arrival order.

Validation and surface

  • Validate payload schema before using: a missing field is a malformed event, not a crash.
  • Event-type whitelist; unknown type = ignore and log, never explode.
  • Replay: acceptance window based on the provider timestamp.

Operations

  • Structured log keyed by event_id (debug correlation).
  • Queue with its own retry and dead-letter (DLQ).
  • Monitor received vs processed; alert if the queue backs up.

Flow

  1. New webhook: define event_id + signature verification BEFORE the handler.
  2. Provider test event: validate signature and end-to-end processing.
  3. Test a real duplicate: send the same event 2x and confirm single effect.
  4. Test replay/lag: an old event must not corrupt state.

Anti-patterns

  • Synchronous processing in the request (provider timeout = lost event and infinite retry).
  • Accepting a payload without signature "because the provider is trustworthy".
  • No event_id: duplicate becomes double effect (2x charge).
  • Empty catch on malformed events: invisibly lost data.
  • Webhook secret in code/commits.

Cascade

  • security: webhook secret handling and rotation, public endpoint surface.
  • debugging: duplicated/lost event investigation.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.