Who invented webhooks? Meet the HTTP POST that never grew up

You wire up a webhook this morning the same way someone wired one up in February 2008. You paste a URL into a form, you pick the events you care about, the other side POSTs to it, your handler answers 200. Eighteen years of protocol design have happened around that exchange, and none of it landed inside it.

The web had the shape before it had the word#

Server-to-server notification is older than its name, and it came out of the blogosphere. weblogs.com launched in late 1999, and for its first years it worked by reading pages: "Updated once per hour, it shows when which sites changed." The inversion came with the XML-RPC interface documented on 30 September 2001, weblogUpdates.ping, one call, aimed at one fixed host, so the blog announced itself instead of waiting to be polled.

RSS 0.92, dated 25 December 2000, added the <cloud> element, whose stated purpose was:

To allow processes to register with a cloud to be notified of updates to the channel.

That is the first registered subscription in the lineage, nine years before PubSubHubbub. The line everybody quotes, "a lightweight publish-subscribe protocol for RSS feeds", is the RSS 2.0 wording.

TrackBack shipped in Movable Type in June 2002, its specification was written up as version 1.0 on 28 August, and it made the author paste a ping URL by hand.

That last detail produced Pingback. On 7 July 2002 at 10:27, Stuart Langridge posted this:

I've got this sort of half-formed idea. It works like MT's TrackBack, but it requires less effort on the part of the user (which is where I think TrackBack falls down). Essentially, it boils down to: when you make a new post, your blog walks through your post and says to every URL mentioned in it: "I'm writing about you."

He invented endpoint discovery by <link> tag in the same post. Fifteen years later that half-formed idea was a W3C Recommendation.

All four share one ceiling: the payload is fixed, the meaning is single, and the destination is mostly not yours to pick.

The date everybody repeats is probably the wrong one#

On 3 May 2007, Jeff Lindsay published "Web hooks to revolutionize the web". The definition, as it read that day:

A web hook is essentially a user specified callback via HTTP POST. This means to support web hooks, you have to somehow allow the user to specify where your application will post to and on what events.

Two clauses, both load-bearing: you choose the URL, you choose the events. Lindsay named Pingback as his prior art in the same piece, and named the delta exactly: "the difference with web hooks is that the payload is varied and the targets are obscure user specified web scripts."

That date is solid: a capture of the blog's monthly index archived on 28 June 2007 lists the post as "Thursday, May 3rd, 2007". Here is the problem. Three primary artefacts put the origin a year earlier.

A Wayback capture from 21 August 2007 of that blog's August 2006 archive index lists a post titled "Web hooks", dated Sunday, August 27th, 2006, with seven comments. Contemporary capture, not a later re-render.

The webhooks.org wiki, written by Lindsay himself and captured on 26 September 2008, lists under Further reading: "Web hooks - The original post about web hooks in August 2006." And his biography, still online today: "While working on a startup in 2006, Jeff wrote about a pattern in web architecture he called 'webhooks'."

Now the part that matters more than the conclusion: what is not established.

The full text of that August 2006 post is gone. Its archived permalink is truncated at roughly 7 KB and cut mid-sentence. What survives of the body is the post's opening, four sentences, the standard 55-word WordPress excerpt:

A while ago I realized something about our ecosystem of web applications that sort of blew me away. Since then, I've been trying to run it by smart people whenever I get the chance. I keep reminding myself that I should blog about it, but I'm not a very well-disciplined blogger. Now, for some reason, […]

Above that excerpt sits an update Lindsay added later, pointing at the wiki he set up in February 2008:

Let's get serious about this shall we? A wiki has been set up to support the growing community interested in web hooks.

Everything past that first paragraph is gone.

Lindsay's republished blog does not carry the post at all, and that URL returns 404, a plausible reason the 2007 date became canonical. One detail cuts the other way: a contemporary capture of the May 2007 index, eight weeks after the manifesto, shows a sidebar reading "Web hooks (1)". One single post in that category.

So the post existed, dated and titled, though not at quite the same evidentiary level as the May 2007 one. That one is attested by the blog's own RSS feed, captured eight weeks later with a machine timestamp. The 2006 post is attested by an archive index captured a year later, on a post Lindsay demonstrably edited afterwards. The update at the top of it points at a wiki that did not exist until February 2008.

Whether it already named the pattern or only sketched it cannot be checked, because the text is lost. What circulated and became the origin story is the May 2007 piece. The formulation that survives scrutiny: the term dates from 2006, the text that spread it is from 2007.

Two days in February 2008#

The pattern entered production inside one week, and nobody noticed.

• 12 February 2008, 20:33:35. The front page of the webhooks wiki is created, anonymously; every edit for the next five days is signed Jeff Lindsay.
• 15 February 2008, 16:33:09. Chris Wanstrath writes version 1 of GitHub's "Post-Receive Hooks" guide. Four minutes later, version 2 adds the line the guide will keep for years: "Send something to Campfire, IRC, Twitter, your CI server, whatever. It's your data." Five minutes later, version 4 adds a link to Lindsay's wiki.
• 18 February 2008, 02:49. The WebHook page appears on the Shopify wiki. Shopify co-founder Tobi Lütke edits it ten minutes later, which tells you where this sat on the company's list of priorities.
• 19 February 2008, 11:16. The May 2007 manifesto is submitted to Hacker News.

Two documented production implementations, two days apart, and both of them, on the page itself, point at the wiki Lindsay had put up the week before. GitHub's guide gained the line "For more information on this technique, see the Web Hooks Wiki" nine minutes after version 1; Shopify's page carries a References section with a single entry, "Webhook wiki". They did not coordinate with each other. They read the same manifesto.

They did not adopt the same vocabulary either. Shopify used the word from day one: its page is titled "WebHook" and its first paragraph reads "WebHooks are a way to tell Shopify to call a script on one of your own web servers." GitHub did not. Its vocabulary stayed "post-receive hooks", then "service hooks". The word surfaces in GitHub's own help pages in October 2009, appears in its API reference in October 2011 as a placeholder inside an example URL, and only becomes the house term in January 2014.

Why no standard replaced the webhook#

PubSubHubbub, drafted from mid-April 2009 by Brad Fitzpatrick, Brett Slatkin and Martin Atkins, drops two words into its abstract that belong on a plaque: "Polling sucks." It became WebSub (the rename commit is 19 November 2016, not the October 2017 that gets repeated) and reached W3C Recommendation on 23 January 2018. Then look at who implemented it: 12 hubs, 7 publishers and 6 subscribers in the official reports, dominated by Mastodon, WordPress, diaspora and Superfeedr. Twitch is the only general-purpose API in the set, and no company sponsored the work.

REST Hooks (Zapier, 10 September 2013) refused the job out loud on day one: "REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions." Three cards down: "Skip the pedantic arguments about standards and implementation details - just use a real solution that works." Last push 13 May 2019, repository tagged deprecated.

CloudEvents is the closest thing to a webhook specification from an actual standards body, and almost nobody cites it. "HTTP 1.1 Web Hooks for Event Delivery - Version 1.0" was committed on 12 April 2018 by Clemens Vasters at Microsoft, under the CNCF, and cites Lindsay's 2007 post as prior art. Its substance is an abuse handshake, so a sender cannot be pointed at an arbitrary site and used to flood it.

They never competed, and I think the reason is that they never addressed the same layer: hub relay for feeds, subscription ergonomics that declined to be a spec, an envelope with an anti-abuse handshake. WebSub is the only one that touched the operational core, and only inside its own perimeter: it makes a hub SHOULD retry and MUST send an X-Hub-Signature, but only for hub-relayed feed content. For a general-purpose webhook, nobody standardised the part that costs you your weekends: signature, retries, ordering, replay.

What the 2023 specification settles, and what it hands back#

Standard Webhooks hit the Hacker News front page on 7 December 2023, and it settles message authentication well. Three lowercase headers (webhook-id, webhook-timestamp, webhook-signature), signed content of msg_id.timestamp.payload, HMAC-SHA256 and ed25519, and a space-delimited signature list so you can rotate a key without dropping traffic. That was the genuinely fragmented part, and verifying one of those signatures over the exact bytes on the wire is the consumer's side of it.

The rest comes back to you, and the document is quiet about saying so. Across its 339 lines there is not one RFC 2119 keyword: no MUST, no SHOULD, no reference to RFC 2119 at all. Svix CEO Tom Hacohen, who committed the first draft of the spec, conceded the point on Hacker News hours after it hit the front page:

We don't call it a standard for that reason... we purposefully made Standard Webhooks more like guidelines than a formal specification.

So retries are recommended, in lowercase, and the arithmetic of backoff, jitter and give-up time stays with the sender. Ordering appears zero times. Replay lives in a section titled "Additional functionality", prefaced with the note that it "is not a core requirement", while the text inside that same optional section calls it "immensely important" to let consumers replay after a long outage.

Now put that next to the earliest archived version of Shopify's wiki page, February 2008:

Don't worry, if your server is down we will simply try again until your server confirms to us that it has successfully received the notification.

A delivery guarantee, written into product documentation fifteen years before the specification meant to codify the pattern reduced it to a suggestion. The strongest promise in this story is the oldest one.

2026 is Groundhog Day: A2A ships webhooks, MCP does not#

Two agent protocols, opposite answers, both checkable today.

A2A shipped webhooks. Announced by Google on 9 April 2025 and donated to the Linux Foundation that June, its 1.0.0 specification defines four RPC methods (Create, Get, List and Delete Push Notification Config). It states the mechanism plainly: "Push notifications are delivered via HTTP POST to client-registered webhook endpoints." That is the whole 2007 definition, restated for agents.

MCP did not. As of its current 2026-07-28 revision, no MCP specification revision has ever shipped a webhook or any outbound callback. Its answer to long-running work is polling (tasks/get) plus an optional long-lived stream, and two webhook proposals were closed, the second unmerged on 15 July 2025.

The roadmap merged on 6 March 2026 files the idea under "On the Horizon", promising a callback mechanism that "would let servers proactively notify clients when new data is available, with defined ordering guarantees across all transports". It was demoted on the way in: the pull request body listed it as a top-four priority, the merged file put it below the line.

A Triggers and Events working group was chartered in late March 2026, co-led from AWS and Anthropic, targeting an events proposal by the end of April. As of 3 August 2026 none has been filed, and the incubation repository has not been pushed since 15 June.

The design sketch that does exist adopts Standard Webhooks as its signature profile, then withdraws the roadmap's promise in its own words: "This design intentionally does not provide protocol-level guarantees around event ordering, exactly-once delivery, or transactional consistency." Webhook order is "best-effort", justified by precedent: "this matches Stripe, GitHub, Shopify, and the Standard Webhooks spec."

Which is where the loop closes. In 2008 the webhook's rival was not polling, it was XMPP. In the Web Hooks Google Group, the busiest thread of the group's first months, opened on 11 November 2008 by Pownce's Leah Culver, was "Cases for Web Hooks vs XMPP?" (five participants, eight messages, still running three days later). And PubSubHubbub's abstract positions itself against XEP-0060 as "dead simple" by comparison. Both times the alternative was richer and heavier. Both times what shipped was an HTTP POST.

And the diagnosis has not moved a word in twenty-four years:

Year	Who	What they said
2002	Stuart Langridge	"it requires less effort on the part of the user"
2007	Jeff Lindsay	"feeds aren't about data coming to you. They're about you getting that data yourself. A lot."
2009	PubSubHubbub	"Polling sucks."
2013	Zapier	"On average, 98.5% of polls are wasted."
2026	MCP roadmap	"clients currently learn about server-side state changes by polling or holding an SSE connection open"

The webhook won by being boring#

In 2008 the receiving end was a PHP script that updated a row. That was the whole argument for the pattern, in Lindsay's own wiki: "getting data from a web POST in PHP is as simple as $_POST['something']".

In 2026 the receiving end acts. It refunds, it books, it opens a pull request, it pages someone at 3am. A missed delivery is no longer a stale cache. And the wire format governing it tells you, in lowercase, that retries are recommended and replay is not a core requirement, while the draft design circulating inside the leading agent protocol's own working group says ordering is best effort.

The guarantees moved to your side of the POST:

• Delivery you can prove, not assume. Every attempt, its status code, its latency, the response body you got back.
• A history that outlives the incident, queryable by customer and by time window, long after your logs rolled.
• Replay that starts a new delivery without erasing the attempts that came before it.

That list is what Repost is built on. It emits the Standard Webhooks headers on the wire, because authentication is the part the specification got right, and it does the operational work the specification handed back.

Frequently asked questions #

Who invented webhooks, and when?

Jeff Lindsay. The word spread with 'Web hooks to revolutionize the web', published 3 May 2007, which is the date everyone cites. But a contemporary archive capture from August 2007 lists an earlier post titled 'Web hooks' dated 27 August 2006 on the same blog, Lindsay's own 2008 wiki calls that one 'the original post about web hooks in August 2006', and his current biography dates the pattern to 2006. The full text of the 2006 post is lost, so whether it already defined the pattern cannot be verified. The safe formulation: the term dates from 2006, the text that spread it is from 2007.

Is Standard Webhooks actually a standard?

Not in the formal sense, and Tom Hacohen, the Svix CEO who wrote the first draft, has said so publicly: the project was made 'more like guidelines than a formal specification'. The document contains zero RFC 2119 keywords across its 339 lines and has never been submitted to a standards body. What it does settle is real and useful: the three webhook- headers, the signed content format, and the symmetric and asymmetric signature schemes.

Does Standard Webhooks require a five-minute timestamp tolerance?

No. The specification names no tolerance value at all. Its entire instruction is to verify the timestamp is 'within some allowable tolerance of the current timestamp to prevent replay attacks'. The five minutes everybody quotes is a constant in the reference libraries, where the JavaScript, Python and Go implementations each apply a five-minute window in both directions. Treat it as a library default, not a requirement of the spec.

Does MCP support webhooks?

Not as of the 2026-07-28 revision. No MCP specification revision has ever shipped a webhook or an outbound callback. Long-running work is handled by polling through tasks/get, plus an optional long-lived notification stream. Two webhook proposals were closed in 2025, and the Triggers and Events working group chartered in late March 2026 missed its end-of-April deliverable with no merged artefact since. A2A took the opposite route and ships client-registered push notification endpoints in its 1.0.0 specification.

Why did no standard ever replace the webhook?

Each attempt worked on a different layer, so they never really competed. WebSub standardised subscription and hub relay for feeds, and, inside that perimeter, a signature (X-Hub-Signature, MUST) and retries (SHOULD), but its implementation base stayed feed-shaped. REST Hooks standardised subscription ergonomics and stated openly that it was not a specification. CloudEvents standardised the event envelope plus an anti-abuse handshake. For general-purpose webhooks the parts that actually hurt an integrator went unaddressed until 2023, and even then only the signature part was settled.

• #history
• #protocol