API Docs Library
A hosted reference for third-party APIs — HubSpot, Airtable, Slack, Notion, Stripe and dozens more — read into every Build with AI turn that targets one, so the request is built from the vendor's current docs instead of the model's memory.
A language model remembers an API the way it was documented when the model was trained: an old version path, a body envelope that has since changed, a required field it never saw. Build with AI used to build HubSpot, Airtable or Notion calls from that memory, and a wrong envelope cost a whole turn to find out. The API Docs Library closes the gap. When a build names a service the library knows — HubSpot, Airtable, Slack, Notion, Mailchimp, SendGrid, Stripe, Telegram, Pipedrive, Trello, Discord, Google Sheets, Brevo, ActiveCampaign, Klaviyo, Twilio, Zendesk, Salesforce, Jira, GitHub, Resend, Postmark, n8n, Make, Zapier and more — WP Webhooks AI reads that service's current reference card on our server and puts it in front of the model before it plans: endpoint and method, the auth header and how it enters the plan, the body envelope, request-level flags, and the errors people actually hit. A service nobody has a card for yet is researched on the spot from the vendor's own documentation and saved for everyone.
What a card holds
One card covers one operation of one service — HubSpot "Create contact", GitHub "Create an issue". It gives the exact URL and method (HubSpot's date-versioned /crm/objects/2026-09/contacts, not the v3 path the model remembers), the auth header and the fact that it should arrive as a credential step rather than a question in chat, the body envelope with a worked example, request-level options such as an upsert flag or an idempotency key, and the 4xx responses that come up in practice with what causes each — a HubSpot portal with GDPR enabled rejecting a contact that lacks hs_legal_basis, for instance. Every card names the vendor page it was verified against and the date, and every URL on it has to sit on that vendor's own documented hosts, so a card can never point the agent at an address the docs do not.
How a build is matched to a card
The service comes from your own words — the name or a known alias, so "Sendinblue" still finds Brevo — and the operation from the nouns and verbs around it: "create a contact" and "update the contact" land on different HubSpot cards. Only what you typed counts. Site data the agent reads back — a credential called "HubSpot PAT", a webhook named after HubSpot — is never mistaken for intent, so a card does not tag along into an unrelated turn. When nothing in the registry matches, one short extraction pass on the first turn asks the model which service and operation you meant, and the miss is recorded either way.
The pill under the reply
Every reply built from a card carries a "WP Webhooks API Docs Library" pill: the service, the operation, the date the reference was verified, and a link to the vendor's page. A card the library wrote for itself is marked auto-researched, so you can see when the request shape came from a curated card and when it came from the same research you could have done. The pill needs the free plugin at 3.2.0 or newer; an older plugin still gets the card, silently.
Researched on the spot
The first time anyone asks for a service and operation the library has no card for, the server goes and reads the vendor's docs — a search, the pages it finds, fetched with a real browser where the vendor's site refuses plain requests — and writes the card from what it read, with a rule that every claim on it must trace back to a page it retrieved. The chat shows "Reading …'s API reference for the first time…" while it waits, usually under a minute, and the wait spends no credits. If the card is not ready in time the build goes ahead on the model's own knowledge and says so; the card is finished in the background and serves the next turn. A curated card always beats a researched one, researched cards are re-read on a schedule, and there is a daily ceiling on research so a run of unusual requests cannot turn into an unbounded bill.
Dynamic URLs it now writes correctly
A GitHub issue lands in /repos/{owner}/{repo}/issues, and the repository often lives in post meta. Build with AI knows the plugin's {{ field.path }} URL templates and writes such a call as https://api.github.com/repos/{{ __repo }}/issues, with a Code Glue snippet that puts __repo into the payload first. A key that starts with __ exists only to fill the URL or a header: it is stripped from the body right before the request goes out, so a value that was never meant for the vendor never reaches it. Static headers such as GitHub's Accept and API-version headers go into the webhook's custom headers.
What it costs and when it is consulted
The lookup runs on the hosted service, so it is available while Build with AI runs on WP Webhooks AI — the free trial or a Pro credit pool. A site on its own provider key keeps building from the model's memory. A card is a few hundred tokens of extra context on the turn that uses it and is billed like the rest of the turn, which works out to about one credit. It fails open: an unreachable library, a card that will not fit, a research run that times out, all land the build back on exactly what it did before, and the reply says when that happened.
/ Related