[garethx]

Requested by Gareth · project thread

Before: hookdeck/webhook-registry#108 (verified sources batch 5, merged) added 55 provider rows and exported doc examples for 21 of them to the registry's samples-doc/ tree. None of the 21 had a directory here.

After: 21 new provider directories with 309 doc-sourced samples. providers.json goes from 272 to 293 providers. The other 34 rows get no directory because they have no published example body: amplitude, apify, aws-eventbridge, bitrise, braze, builder-io, datocms, fireberry, formio, freshsales, hightouch, invoice-ninja, jumpcloud, kobotoolbox, make, new-relic, omnisend, ory, oyster, paperform, paragon, parcellab, prefect, project44, proxyclick, railway, rudderstack, sigfox, speechmatics, tray-io, workato, workspace-one, youcanbookme and zuora. No existing file is changed.

Provider	Samples	Version dir	topic_identifier
360dialog	1	latest	entry[].changes[].field
azure-devops	35	latest	eventType
belvo	9	latest	eventCode
bringg	1	latest	webhook_type
copper	1	latest	null (composed: type + . + event)
currents	1	latest	event
doordash-drive	1	latest	event_name
fourkites	1	latest	MessageType
hasura	1	latest	event.op
iterable	38	latest	eventName
nium	74	latest	list: template, rfiDetails.status
onelogin	1	latest	[].event_type_id
onespan	7	latest	name
opsgenie	16	latest	action
paxos	70	latest	type
pubnub	21	latest	dataSchema
rev-ai	1	latest	null (no discriminator)
socure	8	latest	event_type
strapi	9	latest	event
stuart	12	v3	topic
vtex	1	latest	State
Total	309

How: I copied samples-doc/providers/<p>/ from webhook-registry main (10c5aff3) into providers/, the same way #72 and #73 did. Every file, index.json included, is byte-identical to the export. Each non-null topic_identifier equals the registry row's discriminator path, except nium, whose list adds the row's documented fallback. I checked each one with a port of resolveTopic against every sample, and every non-null one resolves all of its provider's samples to their own topic. Each sample carries source.type: vendor-documentation and its page URL, and each version is marked sourced_via: docs. yarn compile passes (272 → 293 providers, and the compiled topic count equals the file count for all 21). yarn test passes 16/16.

Worth a look:

• PubNub file names differ from their topics. The topic is the wire dataSchema value, e.g. pubnub.com/schemas/events/channel.created?v=1.0.0. The registry harvester writes the file under a safe stem: runs of characters outside [A-Za-z0-9._-] become . and leading or trailing dots are dropped, giving pubnub.com.schemas.events.channel.created.v.1.0.0.json. Compile keys on each file's topic field, so the published keys are the wire values. castle ($list_item.created), descope (Change Password) and flexport (/shipment#created) already ship files named this way. requestReceiver.ts names a captured file topic.replace(/[/:\\]/g, "."), which for PubNub would give pubnub.com.schemas.events.channel.created?v=1.0.0.json. That's the same mismatch castle, descope and flexport already have. A live PubNub capture into latest would write a second file beside the doc sample rather than overwrite it. Both files would carry the same topic, so whichever compile read last would win. Nothing in the repo reads a file by a name derived from its topic, so this PR leaves the receiver alone.

• nium uses the README's list form. The registry row's carrier is template and its carrier note names rfiDetails.status as the fallback. RFI_REQUESTED, RFI_RESPONDED and RFI_CLOSED have no template and resolve through the fallback. The list resolves all 74 samples.

• null rows: rev-ai has no event field (the registry records the discriminator as absent). Its one callback is the job's outcome, job.status: failed, and the sample's topic is job-failed. copper is composed: the registry's carrier note says that neither type nor event identifies the event alone, so the sample's topic is person.update. This follows shortcut in Add doc samples for verified sources batch 4 (32 providers) #73 and check, jfrog and taiga in Add 228 doc-sourced samples for verified-sources batch 3 (30 providers) #72.

• onelogin's carrier is an integer. event_type_id is 5 on the wire. The body is a top-level array, so [].event_type_id reads the first element, and the topic is "5".

• Versions taken from the payload: stuart v3 (every body carries version: "v3"). This follows the README rule.

• Not re-versioned:

  • azure-devops's resourceVersion versions each resource's API representation and differs between samples (1.0, 1.0-preview.1, 2.0, 3.0-preview.1, 5.1-preview.1, absent on four).
  • pubnub's ?v=1.0.0 is part of each schema identifier, and the registry's join_normalization strips it to join the event types. The No Envelope bodies carry no other version.
  • socure's data.workflow_version is the customer's workflow version.

  All three stay latest.

• hasura keys on event.op (INSERT, UPDATE, DELETE, MANUAL), as the registry row does. Its carrier note says a receiver serving several triggers routes on trigger.name first.

• onespan's EDEPOSIT row. The registry notes that the docs table's EDEPOSIT_FAILURE_ATTEMPT row has a payload naming EDEPOSIT_ATTEMPT_FAILURE. That row isn't exported. The two eDeposit samples here are EDEPOSIT_FAILURE and EDEPOSIT_SUCCESS, and each body's name matches its topic.

• strapi also sends the event name in X-Strapi-Event, and the sample carries that header. event in the body is the registry's carrier, and both values agree.

---

Generated by Claude Code

[vercel]

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

Project	Deployment	Actions	Updated
webhook-samples	Ready	Preview	Oct 22, 2026 3:00pm UTC