Payload Library
A hosted reference payload for triggers your site has never fired, so Build with AI can map fields without asking you to fire the event first.
Mapping fields needs an example payload, and until a trigger actually fires on your site there is nothing to map against. The Payload Library closes that gap: 574 hook payloads captured on our own test sites, across 19 sources — WordPress core, WooCommerce and the major form plugins — so Build with AI and the trigger panel can work from the real shape of an event your site has never fired. It matters most on the events that are awkward to produce on demand: a refunded order, a cancelled subscription, a deleted user. A reference payload is always labelled as one, and the moment the event really fires here your own capture takes over.
Your own capture always wins
Three sources are resolved in a fixed order. First this webhook's own capture. Then a capture of the same trigger on another webhook on this site — the payload shape of a do_action is trigger-global, so that is still your real data. Only when the site has neither is the library consulted. A library payload is never written into the site's stored example, so nothing has to be migrated or cleared later: the day the event fires for real, the reference payload simply stops being used.
The shape is real, the values are ours
Wherever a reference payload is in play it is named. The trigger panel shows a "WP Webhooks Payload Library" badge with the build the payload was captured on — contact-form-7 6.1.7, or WordPress itself for a core hook — and Build with AI carries the same badge on every step built from it and on the test delivery that proves it. get_trigger_schema says so in its response too, adding example_source: "library" alongside captured_from, confidence, and the paths it will not let you map.
What a reference payload cannot know
Containers your site defines — a form's fields, post or order meta, ACF — are flagged by name, and their contents are never mapped from a reference payload, whatever our fixture happens to hold in them. Mapping one would ship a null on a build that looks applied, so the plugin refuses rather than advises: a set_mapping or set_conditions step reaching under a site-defined container pauses the build, names the exact paths, and asks you to fire the event once so the mapping is built from your own fields. The trigger panel names the same containers next to the payload.
Always a test delivery
A build made from a reference payload has no capture step to prove it, so it always ends with a test delivery before the webhook can be enabled. That is the check that the mapping survives contact with your site's real data.
When it is consulted
The lookup runs on the hosted service, so it is available while Build with AI is running on WP Webhooks AI — the free 55-credit trial or a Pro credit pool. A site on its own provider key keeps the previous behaviour. A lookup itself costs no credits, and an empty credit pool does not withdraw it — the entitlement is the plan, not the balance. It fails open by design: unreachable, slow or unanswerable, the plugin lands back on exactly what it did before the library existed, and the site is asked to fire the event. Results are cached for a week, misses for a day.
/ Related