fanvue: add 46 doc-sourced samples

[garethx]

New provider: Fanvue (the creator-subscription platform; Hookdeck source type FANVUE). This is the last stage of the add-a-source pipeline. Before it came the skill (hookdeck/webhook-skills#222), the registry row (hookdeck/webhook-registry#94) and the check record (hookdeck/webhook-registry-checks#20).

• Bodies: 46 complete example deliveries, verbatim from the per-family payload reference pages under api.fanvue.com/docs (creator/, checkout/, webhooks/app/*). They were read from the pages' Mintlify .md mirrors. Every one is a full {id, type, timestamp, data} envelope, none is elided, and each file's body.type equals its filename and topic.

• One sample per topic. Five topics have extra variant examples, and only the first in page order is exported. The variants are:

  • creator.payment.succeeded × 3 (paid message, renewal, tip)
  • checkout_link.payment.succeeded × 2 (standard, BNPL)
  • creator.fan.presence_changed × 2 (online, offline)
  • creator.experience_subscription.deactivated × 2

  The harvester reports the extras by heading.

• Not included:

  • 8 live topics with no published body that carries their type: creator.reward.reversed, creator.post.liked, creator.dispute.flagged, checkout_link.dispute.flagged, app.dispute.flagged, app.experience.action.payment.pending, app.experience.action.payment.failed, app.experience.action.dispute.flagged. Swapping type on a sibling body would ship a payload Fanvue never published.
  • app.payment.refunded, a deprecated alias documented as "same body" as app.refund.created. Its type differs and no example of it is published.
  • The 9 deprecated legacy flat events (purchase.new, follow.new, …). Fanvue says their body has an eventId field appended, but none of the eight legacy pages' examples show it, so the published bodies are incomplete by the vendor's own description. Their body also names no topic, so they wouldn't resolve against topic_identifier.

• topic_identifier: type, the top-level body field. Fanvue: "Route your handler on this field, never on a header." It resolves flat in requestReceiver.ts, so a future capture will be named correctly for every enveloped topic. Deliveries also carry an X-Fanvue-Topic header, but its value format is undocumented and it isn't signed, so it isn't used.

• Headers: only content-type: application/json is synthesized (Fanvue documents it). X-Fanvue-Signature is an HMAC over a delivery timestamp keyed with the customer's secret, so docs can't supply it. X-Fanvue-Topic's value is undocumented, so it isn't invented.

• Version: latest. Fanvue has no webhook version scheme, and no body carries a version field. X-Fanvue-API-Version is a REST API request header, not a payload version.

• Provenance: latest is sourced_via: docs, sourced_on: 2026-10-16. Each file carries source.type: vendor-documentation and its page URL.

• Placeholder values are kept verbatim. Fanvue's examples use readable stand-ins like "uuid": "fan-uuid" and "creator-uuid", and they're left as published.

Checklist:

• There's no existing providers/fanvue and no scripts/fanvue harness, so no captures are displaced. Existing files changed: 0.
• Regenerating the registry harvest (harvest_fanvue.py at webhook-registry 25ace60) into a scratch tree is byte-identical to the committed samples-doc/ and to these files.
• yarn compile passes: 152 → 153 providers, 46 fanvue topics, no collisions.
• yarn test: 14/14 passed.
• Registry verify.py: FAIL (0).

Evidence and non-assertions are in hookdeck/webhook-registry#94. Merge order: that PR first, since these files are its samples-doc/ output.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XVonNXXe8TYutXRwopoiHA

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
webhook-samples	Ready	Preview	Oct 16, 2026 4:57pm UTC