webhook-dx-audit

name	webhook-dx-audit
description	Audit the developer experience of any platform that sends outbound webhooks or event destinations to its customers, and produce a structured YAML audit file with scored findings and prioritized recommendations. Use whenever the task is to review, assess, grade, or critique a company's webhook/event- delivery DX: their signup and onboarding, signing and verification, retry and delivery semantics, event catalog and payloads, setup surfaces (UI/API/CLI/IaC/SDK), consumer-facing observability, local dev, and local-to-production transition. Trigger this for a 'webhook DX review', 'event destinations audit', or an 'outbound webhook assessment', even if the user names a specific company (e.g. 'review Acme's webhooks') rather than the word audit. The output is a YAML audit file conforming to `schema/audit.schema.yaml`; whoever consumes it downstream renders their own presentation.
license	MIT
metadata	{"author":"hookdeck","version":"0.2.0","repository":"https://github.com/hookdeck/webhook-skills"}

Webhook DX Audit

Audit how a platform's customers experience its outbound webhooks and event destinations, end to end, from discovery through to production, and produce a scored YAML audit file with specific, prioritized recommendations.

The subject is any company that sends events to its developers (Stripe, Shopify, Paddle, or a smaller platform). You evaluate what their integrating developers actually hit: docs, dashboard, signing, retries, observability, and tooling, using only what is public or already exposed in product.

Scope: webhooks AND event destinations. Treat "outbound webhooks" and "event destinations" as the same audit. The industry terminology is in flux: Stripe popularized "event destinations" (and now delivers directly to Amazon EventBridge and Azure Event Grid alongside webhooks), Shopify ships HTTP webhooks + EventBridge + Pub/Sub destinations and is rolling out "Event Subscriptions" branding, and others still call the whole thing "webhooks". The benchmark for what a modern offering should include is the Event Destinations initiative at https://eventdestinations.org. Score against that broader concept regardless of the platform's chosen label. For a webhook-only platform, criteria that target other destination types are Not Applicable (the destination type breadth criterion in category 6 still scores 0 because the breadth gap is real).

Three states + two scores. Each criterion ends up at 0/1/2, Not Supported (= 0 with intent labeled), Not Applicable (logical exclusion, dropped from math), or Not Assessed (couldn't reach, e.g. dashboard-gated in a Pass 1 run). Pass 1 produces two roll-ups from the same data: a Public-scope grade (what's reachable now) and a Provisional minimum (the floor if human-in-the-loop (HITL) verification never runs). See references/rubric.md for definitions and references/scoring.md for the math.

Audience matters. Declare the platform's intended audience at audit start: developer-platform (where integrators are software engineers), no-code-saas (where integrators are power users wiring up automations through a UI), or mixed (multiple audiences with the webhook surface serving a specific tier). Verify the designation by fetching the platform's homepage and citing specific signals (hero copy, nav structure, customer testimonials, pricing tiers, API prominence); see references/methodology.md step 0 for the checklist. The audience-driven N/A logic in rubric.md removes criteria that don't apply (e.g. IaC and local-dev workflow simulation are N/A for a pure no-code SaaS; under mixed you score by judgment per criterion). Default to developer-platform only as a Pass-1 fallback if the homepage cannot be reached; Pass 2 must revisit with HITL verification.

Perspective: this is a human developer's experience. Categories 1 through 11 score what a person integrating with the platform encounters, so read docs as a human reads them: the rendered HTML pages a developer visits, not .md or llms.txt exports. Whether those machine-readable doc formats exist is an AI-readiness signal scored only in category 12. Keep all AI and agent assessment inside category 12; do not let it bleed into the other eleven. (Fetching a formal API/event spec like OpenAPI for category 4 is fine; that serves human codegen and validation, and is not the same as reading a machine doc export in place of the human docs.)

Fetching the .md export of a page to extract a quote or speed up evidence collection is fine; the rule is that you score what the rendered HTML page presents to a human, not what the .md contains. If the two diverge, treat it as an evidence gap, not a free pass to use whichever is better.

When to use this

Use this for any request to review, grade, or critique a platform's webhook or event-destination DX. The review scope covers onboarding through to first delivered webhook, local dev experience, local-to-production transition, event types, webhook signing, retry support, and examples. See references/program-mapping.md for how findings map to matching Hookdeck offerings when relevant.

Roles: who does what

This is a collaboration. Most of the work is yours (the agent), but some evidence sits behind a login or a UI that only a human can reach. Split the categories accordingly and do not stall waiting on the human for things you can already get.

You (the agent) do unattended, from public surfaces: implementation guidance, event catalog & schema, security & authentication (as documented), delivery semantics (as documented), SDKs & verification (read the actual repo source, not just the README), API/CLI/IaC setup surfaces (docs, Terraform registry), and agent/AI readiness (llms.txt, the hookdeck/webhook-skills repo, any MCP). Plus all scoring math and writing the YAML audit. This is the bulk of the audit.

The human is required for: account creation (signup almost always needs a person for email confirmation, captcha, or a card), and the in-product surfaces that cannot be judged from docs: dashboard configuration, firing a test event and seeing it land, consumer-facing delivery logs, and self-serve endpoint/subscription management.

Critical HITL capture: an example delivery payload. Whenever the human fires a test event or observes a real delivery, they capture and share the full delivery payload (all request headers and the body) with the auditor. The actual delivery often surfaces information the docs do not: which signing mode is active, what the dedup ID header is named in practice, which timestamp format is used, whether any custom headers are set by the operator on the destination, what user-agent identifies the sender. With a payload to score against, the auditor can recommend "document the webhook-signature header you're already sending" instead of the more abstract "add a signature scheme". Without it, recommendations stay conditional ("in default mode the header is X; in Standard Webhooks mode it's Y") and the integrator has to figure out their own situation.

HITL captures fill structured fields, not narrative paragraphs. The delivery payload lands in audit.hitl_evidence.delivery_payload_capture as a structured object (signing_mode, headers map, body, custom_headers_feature_in_use, example values). In-product observations land in audit.findings[].criteria[].evidence strings keyed by criterion id (the criterion the observation scores) and, when audience-driven or HITL-specific, also as records in audit.hitl_evidence.scoring_decisions or audit.hitl_evidence.other_observations. Do not write free-form "HITL Pass 2 lifted the grade from F to D..." narrative into the summary field; the dual-score data already lives in grade.public_scope and grade.provisional_minimum, and the criteria Pass 2 closed live in passes.pass_2.closed_criteria. The summary stays about the platform's webhook DX, not the audit's own process.

Two ways the human covers the gated parts, whichever they prefer:

• Relay: the human clicks through and pastes back screenshots or a few sentences of what they saw, and you score from that.
• Authenticated browser: the human logs in and hands you the session (Claude in Chrome), so you navigate the dashboard yourself with them supervising. Signup itself usually still needs the human.

Default to relay if the human does not say. Never guess a gated capability to avoid asking; mark it Not Assessed (or Not Applicable if a logical rule rules it out) and queue it for the human instead.

How an audit runs

Run it in two passes so the human is only in the loop briefly, with a precise ask. The output of every pass is the audit YAML file (scaffolded from assets/report-template.yaml); there is no Markdown intermediate.

0. Scaffold the audit YAML. Copy assets/report-template.yaml to the path the caller chose. Fill in audit.platform, audit.prepared, and the audit.reviewer block. The default flow is Pass 1 unattended, Pass 2 HITL prompted by the agent (you collect HITL evidence at Pass 2; step 4 writes a sibling hitl-evidence.yaml so a re-audit can skip those asks).

   Pre-load exception. If a sibling hitl-evidence.yaml already exists (a prior run's output, or a preserved capture hand-ported from an earlier audit), read it now and copy the records into audit.hitl_evidence. Skip the Pass-2 asks for any criterion the pre-load already answers. This is the exception, not the norm; most new audits have no pre-loaded evidence.

1. Confirm scope and inputs. Get the platform name and its docs URL. Ask whether the human can provide a test account (and which in-loop mode they prefer). Default to public-only, relay mode, if nothing is said.

2. Pass one, unattended research. Follow references/methodology.md. Work the public surface in this order: the rendered HTML docs as a developer reads them (not .md/llms.txt exports), machine-readable specs (OpenAPI / AsyncAPI / JSON Schema) for the event-schema criterion, the documented signup/onboarding flow, webhook configuration via API, signing and verification, retry and delivery behavior, SDKs, CLI/IaC, and the documented local-dev story. Capture a source link or in-product reference for every claim. Fill in audit.findings and audit.sources as you go; draft scores for every criterion you can settle from public evidence. Do not infer a capability you have not seen evidence of.

3. Hand the human a checklist. Produce a short, specific list of only the things you could not settle and need the human to do or observe in-product, each phrased as a concrete action and what to report back (for example: "fire a test event and tell me whether it arrived, and whether it was signed"; "open the delivery logs and confirm you can see the response body and status"; "capture and paste back the full request payload of one real delivery, including all headers and the body, so I can name the actual signature header, dedup ID, and any custom headers in the recommendations"). If using the authenticated-browser mode, drive these yourself once the human has logged in instead of handing them off. If the run is Pass-1-only by design (no second pass planned), skip the checklist, mark the gated criteria Not Assessed with a one-line reason each, and continue to step 4. The dual-score grade ( and ) will show what was and was not reachable.

Evidence discipline

This audit's value is that it is grounded and specific. A few rules keep it honest:

• Distinguish what you observed from what you inferred. If a doc claims a behavior you could not test, say "documented" not "verified".
• Quote or link the exact doc page, API field, or dashboard screen behind each finding. A finding without a source is a guess.
• Prefer "appears to", "documented as", and "could not confirm" over definitive claims when access is limited.
• Flag absence carefully: "no public documentation of X" is fair; "X does not exist" usually is not, unless you confirmed it.

Output

A structured YAML audit file conforming to schema/audit.schema.yaml. The shape carries:

• header fields (platform, prepared, access, audience, reviewer, passes);
• grade with overall_pct, band, optional dual-score detail (public_scope, provisional_minimum, hitl_headroom_pct), and coverage counts;
• summary (multi-line block scalar, the only large piece of audit prose);
• scorecard (one entry per category, in rubric order);
• findings (one entry per category with per-criterion details, evidence, status, and cross-references);
• recommendations (prioritized list by impact x ease);
• optional embedded hitl_evidence (delivery payload capture and HITL-derived scoring decisions);
• access_limits and sources.

Keep the voice developer-to-developer: concrete, no marketing language, no overclaiming. American English. Whoever consumes the YAML downstream (a customer-report skill, the cloud agent's renderer, a CLI viewer) handles presentation.

Reference files

• references/rubric.md: the 12 scoring categories and every criterion, with 0/1/2 anchors and what to look for. Read this before scoring.
• references/methodology.md: how to find evidence for each category from a public surface, plus the writing tactics that apply to the audit's prose fields. Read this before gathering.
• references/scoring.md: category weights, computation, and grade bands. Read this before grading.
• references/program-mapping.md: maps gap areas to matching Hookdeck offerings, for the recommendations section.
• schema/audit.schema.yaml: JSON Schema (Draft 2020-12) authored in YAML. Source of truth for the audit's structure, locked CategoryId and CriterionId enums, and reserved cloud-agent fields.
• schema/README.md: status taxonomy, dual-score handling, and how to run the linter.
• assets/report-template.yaml: the exact output structure to fill in. Scaffold the audit YAML from this file.