IndieWebCamp is a 2-day creator camp focused on growing the independent web


(Redirected from webmention)


Webmention is a simple way to notify any URL when you link to it on your site. From the receiver's perspective, it's a way to request notifications when other sites link to it. Webmention is a modern update to Pingback, using only HTTP and x-www-urlencoded content rather than XMLRPC requests. Webmention supersedes Pingback.

Concept and v0.1
Sandeep Shetty
See revision history for contributors
Per CC0, to the extent possible under law, the editor(s) and contributors have waived all copyright and related or neighboring rights to this work. In addition, as of 2015-10-05, the editor(s) and contributors (2015-04-07 onward) have made this specification available under the Open Web Foundation Agreement Version 1.0.

Protocol Summary

If Aaron's blog supports receiving webmentions, and Barnaby's blog supports sending webmentions, then this is how they interact:

  1. User Aaron posts a blog post on his blog
  2. User Barnaby writes post on his blog that links to Aaron's post.
  3. After publishing the post (i.e. it has a URL), Barnaby's server notices this link as part of the publishing process
  4. Barnaby's server does webmention discovery on Aaron's post to find its webmention endpoint (if not found, process stops)
  5. Barnaby's server sends a webmention to Aaron's post's webmention endpoint with
    • source set to Barnaby's post's permalink
    • target set to Aaron's post's permalink.
  6. Aaron's server receives the webmention
  7. Aaron's server verifies that target (after following redirects) in the webmention is a valid permalink on Aaron's blog (if not, processing stops)
  8. Aaron's server verifies that the source (when retrieved, after following redirects) in the webmention contains a hyperlink to the target (if not, processing stops)

Unmentioned but implied (and vaguely mentioned in the pingback spec):

  • Aaron's server displays the information about Barnaby's post somewhere on Aaron's post.

See the webmention specification for a full description of the protocol.

See comment: how to accept a comment for more details on accepting comments in general and displaying them.



Why webmentions (e.g. instead of Pingback) and why you should implement them.

Webmentions are:

  • Simpler. By dropping XML-RPC, webmention is simpler than Pingback. This means:
    • Less work to implement
    • Easier to test
    • Both of which combine to enable more reliable, interoperable implementations, sooner.
  • Re-using only HTTP enables easier testing and UI. By using only HTTP, it's possible to construct simple HTML forms that exercise the protocol, which is a good design principle for web protocols in general[1]. This enables simpler/easier testing (with just a static HTML file), and the ability to provide simple (no JS needed) webmention submit forms on blog posts for others to paste URLs to their replies (some IndieWeb participants are already doing this, e.g. and posts).

How to

How to Send Webmentions

How to Receive Webmentions

How to Test Webmentions

Sending Webmentions

The beauty of simple protocols is that you can do most of this manually very easily.

  • Given a target to which you want to send a webmention, you need to first discover it's webmention endpoint:
curl -i -s $target | grep 'rel="webmention"'
    • Note: this is only an approximation, your implementation MUST accept a "webmention" value among the space separated set of terms in the 'rel' attribute. Older implementations may use rel="" and some may use both: rel="webmention" neither of which are discovered by the grep above. Some may use single quotes (or no quotes at all) to surround the webmention rel value. Still others may only support discovery with an HTTP Link header (e.g. Taproot). Compliant implementations must check the HTTP Link headers for the rel value first, and if not found then parse for the rel value on a <link> or <a> element in the <head> per the HTML specification on parsing rel values.
  • Now to send the webmention:
curl -i -d "source=$your_url&target=$target_url" $targets_webmention_endpoint

One-liner webmentions

This will send the webmention in a single command:

curl -i -d "source=$your_url&target=$target_url" `curl -i -s $target_url | grep 'rel=""' | sed 's/rel="webmention"//' | grep -o -E 'https?://[^ ">]+' | sort | uniq`

See also this gist for sending pingbacks manually:

Accepting Webmentions

Currently the easiest way to test consuming webmentions is to implement sending them, then send yourself mentions.

Once you’re ready to test integration with another site, you can either ask someone in IRC to send you a comment, or mention your page in IRC and send a webmention from IRC log URL for that line to your URL.

For example this IRC line links to Pasting the URL for the IRC line into the webmention sender will send webmentions for all the links on the page. Then you can check your page or your server logs to see if the webmention was successful — in this case the comment successfully showed up on the target page.

Implementation Details

There are some interesting implementation details regarding receiving webmentions. E.g. when to follow redirects and when not to.

endpoint discovery

In step 4 in the protocol summary above, when performing webmention endpoint discovery, implementations MUST check for the webmention and SHOULD check for (for backward compatiblity) as rel values which may be present among a space separated set of rel values inside a rel attribute.

Also note that endpoints may be advertised in both <link> and <a> elements. Supporting <a> is important for sites like that don't allow link elements at all.

must follow redirects

In steps 7 and 8 above, implementations MUST follow redirects of the target and source URLs.

checking target validity

In step 7 above, when the webmention receiver checks the target URL for validity, follow any HTTP redirects and use the resulting URL when checking for validity.

For example, if your posts visibly show permashortlinks for others to copy/cite/link to and someone sends a webmention to a shortlink, be sure to resolve any redirects before checking if it’s on your site, or matching it up to a post on your site.

The webmention receiver should then check if the target is valid and supported. A valid target is one that is recognized by the receiver.

In simple cases, this is just a check that the target URL exists on the receiver's domain. The meaning of "valid" can be extended to also include:

  • mentions of pages that don't exist on your site (in case you want to track possible lost URLs)
  • mentions of POSSE URLs

use cases

  • Webmention proxy servers such as and are able to accept webmentions for other people's sites
  • Enables indieweb-friendly silos to send backfeed webmentions for comments and responses to the original post of a POSSE copy on that silo.
    • i.e. if you POSSE to a silo, you should accept webmentions where the target is your POSSE copy
    • This requires indieweb-friendly silos send webmentions to the original site's webmention endpoint, so the silo will need to know that one of its posts is a POSSE copy

You should also support receiving webmentions where the target is one of your POSSE copies.

verifying source links to target

In step 8 above, as the webmention receiver, to verify the source URL:

  • retrieve it following redirects,
  • when checking the resultant HTML, look for the target URL as literally provided in the webmention request (i.e. NOT redirects from target)

For example, if you get a webmention with source= target=

sync or async response status code

Webmention receivers can choose to verify the webmention synchronously (process immediately) or asynchronously (add it to a queue for processing later). High level difference:


  • upon successful verification the receiver MUST return a HTTP 200 Success response


  • receiver MUST return HTTP 202 Accepted.

See the Brainstorming section for some additional thinking on this.

types of mentions

In addition to just a link (mention) there are several special types of mentions, each which have markup for detection and specific implementation recommendations:

accessing endpoints in the browser

Some implementations now display a page that briefly explains webmentions when the webmention endpoint is accessed in a browser.


IndieWeb Examples

The following users/sites have implemented sending and or receiving webmentions, in rough chronological order:

  • Aaron Parecki using p3k on as of 2013-05-26. Details:
    • All posts send webmentions (as of 2013-05-26 first (semi-)automatic webmention sent on 2013-03-31) upon posting (asynchronously with posting UI, no results reported).
    • Events, notes (including RSVPs), replies accept webmentions (as of 2013-05-26)
    • Discovery with both: rel="webmention" and rel="" links in head, and HTTP Link: rel=" header
    • Notes (including RSVPs), replies have an input form for pasting in your comment URL to conveniently send a manual webmention (as of 2013-10-12)
  • Ben Werdmuller using idno on as of 2013-05-31. Details:
    • All(?) posts send webmentions as of 2013-05-31 and accept as of 2013-06-??
    • Discovery with both: rel="" and rel="webmention" links in head, and with HTTP Link: <>; rel="webmention"
  • Barnaby using Taproot on as of 2013-06-11 (per git). Details:
    • All notes and articles accept (as of 2013-06-20) and send webmentions (as of 2013-06-11) upon posting (posting UI returns response content to the browser, then synchronously sends webmentions)
    • Incoming webmentions for notes and articles are parsed and stored, displayed for notes (comment updating as of 2013-06-23) but not yet articles
    • Discovery only with HTTP Link: <>; rel=""
  • Jeremy Keith on as of 2013-09-15. Details:
    • All blog posts accept webmentions
    • Discovery only with: rel="webmention" link in head
    • Blog posts have an input form for pasting in your comment URL to conveniently send a manual webmention
  • Barry Frost on as of 2013-09-15[2][3]. Details:
    • All(?) posts send and accept webmentions
    • Discovery with: rel="webmention" link in head, and HTTP Link: <>; rel="webmention" in header
    • Posts have a hyperlink in footer "How to comment on this post" to instructions detailing posting an h-entry with h-card and how to send a webmention.
  • Christian Weiske receiving webmentions on as of 2013-10-22. Details:
    • All posts accept webmentions using stapibas
    • Discovery only with HTTP Link: <>; rel="webmention"
    • Approach for sending webmentions (with fallback sending of pingbacks)
      • check self Atom feed, if there are updates then proceed with discovery/sending for each update, for each link in the update: do a HEAD request first, do discovery for webmention endpoint, if none found, do discovery for pingback endpoint, if none found and the resource is 'application/xhtml+xml' or 'text/html', do a GET request, do discovery for webmention endpoint, if none found, do discovery for pingback endpoint. send webmention if an endpoint was found, otherwise send pingback if an endpoint was found.
  • Bear on as of 2013-12-01.
    • All posts send and accept webmentions
    • Discovery with both: rel="webmention" and rel="" links in head, and HTTP Link: rel=" header
    • Incoming webmentions are validated and stored, but not yet added to the appropriate articles
  • Kartik Prabhu on as of 2013-12-03.
    • All articles & notes accept webmentions
    • Articles have an input form for sending a manual webmention inspired by The form prompt links to the webmention endpoint.
    • Webmentions are saved as responses and appear below the article classified according to response type.
    • Webmentions are sent manually for all posts.
  • Jeena Paradies using a home grown Rails app on as of 2013-12-06. Details:
    • All homepage, blog posts and notes, photos, comments and events accept webmentions
    • Discovery with: rel="webmention" Link: in HTTP header
    • Sends webmentions on create, update and delete, no salmentions yet
    • Has a manual form
  • gRegor Morrill sending and receiving webmentions on as of 2014-02-04.
    • Using a custom plugin I developed for Nucleus CMS
    • All articles can receive webmentions
    • Webmention endpoint is broadcast via Link: HTTP header and <link> element
    • Incoming webmentions validate the target is a valid URL on and the post ID in the URL is valid.
    • Webmentions are parsed and further validated asynchronously. Replies/mentions are displayed interleaved with "local" blog comments..
    • More implementation notes
  • Glenn Jones using node.js module on as of 2014-02-19.. Details:
    • All notes accept webmentions
    • Discovery only with: rel="webmention" link in head
    • The notes editor has an input for the in-reply-to URL
    • The webmentions module allows pinging of webmention between any sites
    • Yet to implement: full authorship parsing, updates, deletes.
  • Ben Roberts sending and receiving webmentions on as of 2014-04-24
    • Parsing replies, mentions, and likes. Rsvps are handled as just mentions currently.
    • Discovery with both: rel="webmention" and rel="" links in head, and HTTP Link: rel=" header
    • Currently uses vouch and a whitelist while all others are sent to moderation.
    • Processing happens asynchronously by cron job.
    • Submissions return a link for queue record that returns a status as a Webmention-Status header as well as a minor note in the body.
    • Attempting to keep implementation notes as a modified spec at webmetion0.2-b1
    • Sending is done automatically when post is made.
  • Will Norris using on as of 2014-07-31. Details:
    • All posts accept webmentions, but none are displayed (yet)
    • Webmentions sent on-demand via command line application that handles the discovery bits
    • Discovery only with rel="webmention" link in head
    • Advertised webmention endpoint is on-site, but POSTs are proxied to (documented here)
    • Previously used webmention plugin for WordPress as of 2013-06-23
  • Joel Dueck receiving webmentions on as of 2014-09-23.
    • All posts accept webmentions as well as traditional comments.
    • Webmentions (if valid) are logged to a text file and sent to Joel via email. Those that pass moderation are manually added to the target post as a comment (which on this site means it is included in the blog and sent to email and RSS subscribers as well as being appended to the target post).
    • Endpoint is a modified version of Jeremy Keith's webmention.php.
    • Webmentions sent manully. More to implement. To-do list is long. Site is running Textpattern CMS, so a complete webmentions plugin is both feasible and ideal.
  • Dan Lyke receiving webmentions on blog entries as of 2014-10-10.
    • Webmention endpoint is broadcast via <link> element and <indie-action> element.
    • Currently only displays links on title text back to source URLs
  • Johnny Oskarsson receiving webmentions on as of 2014-10-23.
    • Webmention endpoint is broadcast via Link: HTTP header only.
    • Pages marked up with h-entry in-reply-to show up as comments, others won't show up at all. (but they will be logged)
    • Webmentions are sent manually for now.
  • Stuart Langridge sending and receiving webmentions on as of 2014-11-29.
    • Write up linking to various bits of code for Pelican, the Python static site generator, at "Enabling Webmentions".
    • Webmention endpoint is declared in the HTML with a <link> element, because HTTP headers are a pain in the behind to set up by comparison.
    • Uses Pelle Wessman's webmention Heroku endpoint as endpoint, and then some Python to fetch and bake in webmentions on site regeneration, and some JS to pull them in live.
  • Giovanni T. Parra receiving webmentions on as of 2015-02-28.
    • Wrote Jekmentions, a small service that works as a webmention endpoint for Jekyll sites hosted on GitHub that sends the webmentions received as files in commits to the GitHub repository.
    • Webmentions are sent manually for now. Some are being sent, but only through to twitter.
  • Amy Guy sending webmentions automatically for all links on all posts on as of 2015-05-?.



For webmention endpoint discovery:


Handling receiving webmentions:

For parsing the mentions, the following may come in handy:


The following tools show how a notification could be sent upon receiving a webmention

Publishing Software

Some open source publishing software supports webmentions.

  • Known sends webmentions and accepts webmention comments
  • p3k sends webmentions for all posts and accepts webmention comments on events, notes, replies, RSVPs
  • phorkie sends and accepts webmentions to notify remote instances about forks
  • Taproot

Plugins exist for some open source publishing software:


Some services one can use to receive or send webmentions. receives webmentions for any registered page and allows them to be embedded through javascript.


Main article: Bridgy is a service that sends webmentions for comments/replies, likes, and reposts on Facebook, Twitter, Google+, and Instagram posts. It uses original post discovery to find target links for the webmentions. GitHub repo here.

Bridgy Publish also supports webmention as a mechanism to trigger POSSEing to Facebook, Twitter, and Instagram.


stapibas is a self-hosted service to send and receive webmentions for websites and blogs.

It can be used to send out webmentions and pingbacks for new posts on static sites.

Main article: is an open-source project and hosted service for receiving webmentions and pingbacks on behalf of your indieweb site.


Main article: Jekmentions

jekmentions is a service that works as webmention endpoint and saves the received webmentions in a GitHub repository, so that they can be used and shown in a Jekyll blog.

checkmention lets you test your webmention implementation on your indieweb site, and whether it robustly detects certain types of XSS attacks. It also allows you to test for authorship spoofing.


node-webmention-testpinger is a tool to ping your site with a variety of webmentions markup. Contains copies of a couple of real world examples of mentions that it enables you to ping locally to a development copy of your site.


node-webmention-testendpoint is tool to test your webmentions client. Generates a demo-post and a demo-endpoint to test if your client parses the webmention-endpoint correctly and to check if the ping body is transmitted correctly.


Tools you can install to send webmentions

Firefox Addon

Wish List

  • A tiny, no-dependencies js file which can fetch indiecomment data from and dump it into an element, enabling 2-step indiecomment support:
    • Add a <link> to
    • include this script and add some <div data-indiecomments data-url="blah"></div> element where you want them to appear


Why webmention instead of pingback

See Why above.

Why webmention instead of Trackback

Main article: Trackback
  • Trackback, lacking link verification, is more easily and heavily spammed
  • Plus all the reasons why webmention instead of pingback

Which links should receive webmentions

Which links in a post should receive webmentions?

Webmentions should be sent to all URLs a post can be considered to mention — this includes

  • in-reply-to URL(s)
  • rsvp URLs
  • URLs linked to in the content, including URLs of people mentioned

What do existing implementations do?

  • I send pingbacks (webmentions coming soon) to the in-reply-to URL if set, and all URLs in the post content field. 09:14, 10 April 2013 (PDT)

Should webmentions be sent for links to static assets

Should webmentions be sent for links to static asset URLs e.g. images, audio?

What do existing implementations do?

  • Taproot sends webmentions to all URLs in a post without discriminating by type of link --Barnaby Walters 09:01, 26 November 2013 (PST)
  • Stapibas sends linkbacks to all URLs, independent of their type -- User:Cweiske

Should webmentions be sent for embeds

Should webmentions be sent for resources embedded in a post like the URLs in "src" and "data" attributes?

  • <audio src>
  • <embed src>
  • <iframe src>
  • <img src>
  • <object data>
  • <source src>
  • <video src>
  • ... others?

And what about "srcset"? Is anyone on the indieweb even bothering to publish with srcset?

What would the receiver of a webmention for an embed do with that notification?

Should webmentions be sent for removals

Main article: deleted
  • If the source post is edited to remove a link to the target, should a webmention be sent to the target to inform them of the removal of the mention?
    • [] sends webmentions to links that are removed while editing an article.
  • Do any implementations for receiving webmentions do anything with such a webmention POST?
    • [] deletes the existing mention-response from database, if it receives a mention where the source no longer links to target.

How does this solve the spam problem

How does this solve the spam problem that plagued Trackback and Pingback?

Trackback was particularly susceptible to spam since the URL and content of the comment was sent in the payload. Pingback improved on this by making the "ping" only contain the URL of the comment, so that the link could be verified.

Webmention is a simplification of Pingback, so by itself does not provide any new anti-spam measures.

Instead, spam is treated as its own issue, with several possible solutions being documented on the Spam Prevention page, including most recently, the Vouch protocol.

In practice, Webmention receivers look for specific h-entry markup to render comments, likes, reposts, and other responses, which all add a minor barrier (for now) for spammers above and beyond Pingback.

POSSE or Send Webmentions First

Should an indieweb publisher POSSE first, or send webmentions first?

It is better to POSSE a post first, and then send webmentions for all links in a post, for two reasons:

  1. Easier de-duplication at the receiver. By sending webmentions after POSSEing and adding u-syndication links on your post to the POSSE copies, the webmention receiver(s) will see those u-syndication links and be able to use them immediately to de-duplicate any proxy webmentions it may have received due to your POSSE copies. The opposite order is harder to de-dupe since it requires original-post-discovery which is more work than simply getting u-syndication links from parsing the h-entry.
  2. POSSE reply threading. When indie A replies to indie B and sends B a webmention, when B goes to reply back to A, if B's copy of A's post already knows the Ap POSSE copy, then B can immediately reply back both to A, and POSSE reply thread their Bp POSSE copy to Ap.

Reference: 2015-05-28 IRC discussion/background

Why is the target URL a required parameter

Technically, the "target" parameter does not add any semantics to the webmention request. Without the target parameter, the webmention request means essentially the same thing, which is indicating the source URL may be of interest to the webmention endpoint.

By including the "target" parameter in the webmention request, it makes verifying the webmention easier for the recipient, since they have an exact string to look for on the source page. With the target parameter, the receiver searches for an exact match. Without the target parameter, the receiver doesn't know exactly what to look for, and would have to look for any link matching the receiver's domain, adding complexity to the verification code.

Additionally, since the receiver also must follow redirects on the target URL, expecting the receiver to follow redirects for all URLs on a page is unreasonable. Having a single URL to follow is much simpler.

Since it's no extra burden on the sender to include the target parameter, and makes verification easier for the receiver, including the target parameter is required in the spec.

Also, a webmention endpoint may handle multiple possible target sites, as does, for example, so can't make an a priori choice about which domain to check the source for links to.

Issue: "Possible" handling of multiple target sites is at best a feature of a Webmention endpoint. It is not documented or even expected in the current Webmention recommendation. -- 07:42, 26 July 2015 (PDT) Sarven Capadisli

  • Similar to the reason we have a webmention endpoint in the first place (rather than having the URL handle webmentions itself), we prefer to design protocols that don't limit the implementation details. Having the ability for an endpoint to handle multiple domains is a good thing, and we should not design the protocol where that is impossible. Aaron Parecki 08:01, 26 July 2015 (PDT)


DDOS attack vector

Webmention, like Pingback, is a vulnerable vector for DDOS attacks. See DDOS for more discussion and proposed solutions.

3rd party tracking exploits

Third party visitor tracking (or possible exploit) via nocache icons. See [4] for details.

  • Known implements a fix for this where icons are locally saved as of September 7, 2014. Ben is interested in other approaches.

client unsure can read response

Not specifying a required response format and/or structures of the response formats is problematic as a client can never be sure they’ll be able to read the response.

  • Fortunately, as Aaron Parecki noted, if there is an error, knowing exactly what caused it isn’t really very helpful apart from debugging, where the response will be read by a human anyway
  • Rough consensus seems to be to default to a plantext error/success message, or if an accept header is given then maybe serialise it as requested, e.g. HTML or JSON. [5] Use case for HTML is in-browser sending 08:58, 22 October 2013 (PDT)

should bookmarks send webmentions

Should bookmarking (i.e. publishing a bookmark post) send a webmention? What if there are 1000's of bookmarks? how do you distinguish between normal links and bookmarks? -

  • I think bookmarking should yes, just as favorites and likes do. - Tantek 14:53, 13 August 2013 (PDT)


Asynchronicity: a server may want to queue webmentions for source retrieval processing and do that asynchronously with the request. It's not always practical or advisable to handle all that processing in the actual HTTP POST thread. Thus receivers of webmentions must not be required to return no_link_found errors. - Tantek 14:53, 13 August 2013 (PDT)

repeat webmentions not an error

Updates: it's acceptable to send a repeat webmention, e.g. for updating or deleting comments. Thus the already_registered error must not be required, and should likely not even be an error in the first place. - Tantek 14:53, 13 August 2013 (PDT)


This section likely deserves its own article, deduplication (canonical name per Wikipedia article [6]), since there is an IndieWeb example, a non-webmention silo example, and applicability to comments independent of notification mechanism (webmention).

De-duplication (AKA de-duping deduping): replies and other responses are often duplicated in different places, e.g. via backfeed of POSSEd replies by Bridgy. Ideally, recipients should try to de-dupe webmention sources, preferring an original post (see below). Getting this perfect is hard, but getting close is pretty easy (see one IRC discussion and another) by comparing an incoming reply (etc) to existing replies based on:

  • u-uid
  • u-url
  • rel-syndication (also compare to u-url, and vice versa)
  • other u-in-reply-to links in the incoming reply
  • full text, after stripping HTML tags and probably ignoring whitespace differences
  • text prefix, after also stripping leading @username, RT/MT, trailing ..., etc.
  • edit distance, longest common subsequence, or other fuzzy match

Examples / challenges for de-duping (use these as source material to check any de-duping approaches / algorithms)

IndieWeb Examples:

Silo examples:

  • Twitter: ~24hr(?) dedupe. In their web create UI, if you enter the same text as a previous tweet in the past 24hrs (tested minutes, and years, educated guessing 24hrs) and attempt to "Tweet", Twitter won't post it, and will instead show an error message of "You have already sent this Tweet.".

prefer original posts

prefer original posts - an alternative to implementing de-duplication is to simply always prefer original posts (replies) rather than their POSSE copies. You can implement this by:

  • always do original post discovery on the "source" URL
  • if there is an original post,
  • use it instead of the source URL.
  • thus: if/when your post receives Bridgy webmentions of POSSE copies of replies, you can find, retrieve, and display the original replies instead (i.e. treat it as if you received a webmention for the original).
  • if you also receive a webmention for the original later (or before), you merely treat it as an update webmention using your existing update handling code path.

bad interpretation of h-feed source

  • if the source URL contains multiple posts where only one references the target post (e.g., a homepage h-feed, sent accidentally or "maliciously"), target may interpret it as many comments (see [7] for an example)
  • mitigation: webmention receivers should look for a backlink in the first h-entry on a given source page only.


using x-forwarded-for to mitigate DDoS abuse

When verifying a webmention by checking the source site, include an X-Forwarded-For HTTP header in your request, with the value set to the IP address of the client that notified your server of the alleged webmention.

That is, to verify, do something like:

   curl -H "X-Forwarded-For:$sender_ip" $source

where $sender_ip is the IP address of the incoming request that informed you of the webmention and $source is the source page of the alleged webmention. Then check the response to see whether a link to $target is present.

For more, see DDOS#Forward_originating_IP_address.

Note: WordPress is using X-Pingback-Forwarded-For to mitigate abuse of pingbacks. And IETF is also in process of standardizing a Forwarded header (with a more detailed semantics). If someone feels strongly, we could pick one of those or mint something new, but in the meantime, use X-Forwarded-For.

rel-webmention on <a> tags

Does it make sense to allow rel=webmention on anchor tags in addition to link tags?

  • pro: (and maybe other hosted platforms?) prevent users from adding custom <link>s, but allow <a>s
  • con: webmentions are basically machine-only; no user-facing data
  • pro: GET request to webmention endpoint could return a helpful page with a link to webmention ("visible endpoint that teaches" [8])
  • See this pull request to the webmention spec

These libraries and implementations support <a> webmention endpoint discovery

  • PHP: mention-client library [9]
  • Ruby: webmention gem [10]
  • Python: webmention-tools [11]
  • Python: Red Wind [12]
  • ...

These webmention endpoints show human-friendly information, when visited with a GET request

Asynchronous status polling

Asynchronous status polling could be achieved via the webmention receiver returning a LINK header with rel=status with a URL for querying the status of a specific pending webmention request.


LINK: <> ; rel="status"

Then the sending of the webmention could poll that URL for updates on the status of that particular webmention.

  • It's nice to reply to a webmention request with HTML including a link to the status location (particularly useful for mentions sent via a form). I would prefer to put the rel="status" on that visible link instead of the header 19:07, 19 August 2014 (PDT)

Status Query Results

In order to distinguish between the layers of a request to the status page and the actual current status of the webmention, the page could return an additional header to explain that status of the webmention processing. This could be the same code that would have been returned if the webmention were just submitted.


HTTP/1.1 200 OK
Webmention-Status: 202

This would say that the webmention is still in the state of "accepted" but has not processed yet. This also leaves the page body open to any formatting for the user's view.


IndieWeb community members who have implemented this


Asynchronous status notification

Asynchronous status notification could be achieved by using a webhook in the initial webmention request.

I.e. in addition to:

  • source=URL
  • target=URL


  • callback=URL

to the webmention POST request.

Webmention receivers should optionally support the "callback" parameter by calling it back (doing an HTTP POST to it) upon completion of processing of the webmention, with a "status" query parameter indicating the outcome of webmention processing. See "More status codes" below for possible values for that parameter.

Example payload sent to the callback URL:


More status codes

Synchronous webmention receivers should return the following status codes:

  • 200 OK - the webmention was somewhat processed (i.e. preconditions checked out), but any of the following conditions may apply:
  • 202 Accepted - the webmention is still queued for processing
  • 400 Bad Request - for any of the following conditions:
    • Source URL not found
    • Specified target URL not found
    • Source URL does not contain a link to the target URL
    • Specified target URL does not accept webmentions


Similarly, in an asynchronous interaction, the callback webhook should include a "status" URL query parameter with the status codes noted above.

Discovery in PHP

The following code is a set of simple short & flat functions for doing discovery of webmentions in PHP.

Automatic discovery could be implemented in PHP by:

  • look for a link header using a HTTP request library to get the rels
    • link_rel_parser.php :
      • use head_http_rels($url) to curl a HEAD request and from the return value info get back HTTP info["status"] and info["rels"] as a rels array if any.
      • if you already have the raw HTTP header, use http_rels($h) to get a rels array
    • and then lookup rels["webmention"] for webmention endpoints
  • if no Link: for webmention found AND info["type"] == "text/html" or "application/xhtml+xml" then
    • use PHP DOMDocument to search the retrieved document for the first <link rel="webmention"> element (or first that matches selector: link[rel~=webmention] ) e.g.:
$w = 0;
$c = curl_init($url);
curl_setopt($c, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($c, CURLOPT_RETURNTRANSFER, true);
$s = curl_exec($c);

$dom = new DOMDocument();
$domx = new DOMXPath($dom);
$ws = $domx->query(xphasrel('webmention')); // except with link instead of *
if ($ws) {
  $w = $ws->item(0)->getAttribute('href');
// if ($w!=0) then it has a webmention endpoint.
// this code could be changed into a html_webmention_rel($url) function,
// to be called only if head_http_rels($url) returns no "rels" array 
//   or has no "webmention" item(s) in said array

Alternatively see mention-client-php for an object-oriented implementation.

Variable Response Body Problem

To deal with the variable response body problem:

  • Make response body optional
  • Send the error information in a response header, probably similar format to status
    • E.G. X-Webmention: 16 Source URI Not Found or X-Webmention-Response: 17 Not Linking
    • Re-use the semantics + error codes from the pingback spec [17]

propagation to a mobile device

To make webmentions more useful, it would be great if there was some way to have them propagate as notifications to whatever devices the user has setup to receive such notifications.

homepage webmentions

See: homepage: webmention to homepage.


Good retry logic can be hard, regardless of what you're doing, and webmentions are no exception. Here are some current practices we use to retry HTTP fetches for webmention endpoint discovery, sending webmentions, and fetching source pages to check backlinks.

  • Bridgy gives up immediately on 4xx errors and DNS lookup failures. On other errors (mostly 5xx and connection failures), it retries 30s later, backs off exponentially down to once an hour, and gives up after 3d.


Webmention spam is not (at time of writing) really a problem; it'd be nice to keep it that way. A proposal: add a hashcash-like "proof of work" to a webmention request. In essence, this is a calculation which takes a little time to do; not enough to impact an individual sender, but enough to make large-scale webmention-sending (i.e., spam) problematic.

epoch hashing

Proposed approach (suggestions from crypto people are welcome!) In addition to source=http://source/article&target=http://target/whatever POST parameters to the webmention endpoint, also pass two new parameters: time=1417292519&nonce=5684712. The time parameter is UTC epoch time (seconds since 1970), and the nonce is calculated such that sha256(target + "-" + time + "-" + nonce).hexdigest() startswith "000000". The number of zeroes required can be varied before specifying this approach to "tune" the difficulty of creating a nonce; the above (6 zeroes) takes some seconds on a reasonably modern machine.

A webmention endpoint then checks that sha256(target + "-" + time_parameter + "-" + nonce).hexdigest() really does start with "000000", and that time is not too long ago (to prevent replay attacks; "not too long ago" is intentionally vague here because one must consider clock drift and so on).


Possible alternative: set up where one submits the proof of work to and if it verifies, h-f-c then vouches for you as per Vouch. What should then happen is that if people generally agree that h-f-c is requiring a proper proof-of-work, everyone whitelists it. So it's all done on the back of Vouch, but it doesn't have Vouch's clique problem.

A working implementation of this is at Hash for Vouch and described in detail there and on

plain hashcash

Hashcash for Vouches seems like overengineering.

Why not just attach a hashcash to the webmention itself?

If you were sending a webmention from to, you'd take the target URL, calculate a hashcash for that URL, then send that as an extra parameter in the webmention.

To specify the hashcash bit level, we could use a meta tag like this:

<meta name="webmention-hashcash" content="20" />

If you get a hashcashed webmention and you do support it:

  • check to see if it follows the expected text format of a hashcash and that it contains a URL you care about and/or control
  • if it doesn't, treat it as if it has not been hashcashed (or discard it if the URL doesn't match)
  • if it passes the expected format test, check the hashcash
  • if it passes, post it to your site
  • if it fails, discard it

If you get a hashcashed webmention and you don't support hashcash, simply ignore it.

Performance testing:

verifying private webmentions

If you receive a webmention from a web page that requires authentication to access it, the normal webmention verification process will fail. What is the best way to have the webmention endpoint authenticate as the receiver's website to be able to fetch the private page?

Main article: private-webmention

checking endpoint once per domain

Currently the spec requires webmention discovery on every URL you want to send a webmention to. If your post links to three separate notes on the same website, for every webmention you need to check the note’s page to discover the correct endpoint even though these are likely to be the same. Would it be safe to assume only one endpoint per domain? (From IRC 2015-06-15.)


Alternatives to webmention.

LINK verb

James Snell brings up a suggestion to use the HTTP LINK verb to send the webmention notification. This would remove the need to first make the discovery request to find the webmention endpoint, since it could immediately send the LINK request to the URL itself.

Problems with LINK verb:

  • It's way less likely to actually get adoption using the LINK verb. The discovery step adds an opportunity to add a layer of indirection, which lets us separate the server that handles the webmention. While discovery is an extra step, but at the same time it provides a lot of benefits.
  • For example, it wouldn't be possible to have a static HTML site handle the HTTP LINK request, whereas it could delegate to a webmention service by using the <link> tag.
  • Additionally, some hosting environments may not provide a way to handle the LINK request where a normal POST would work instead.

Because of the benefits and flexibility the discovery step adds, we need to stick with it and can't use the LINK verb as cool as that might be.

Resolved Discussions

rel webmention addition to registry

  • rel=webmention should be added to the HTML5 rel registry (supercedes/obsoletes IETF/IANA 'Web Linking').
    • I'll take this up if there is enough consensus that we need it. I prefer the current URL based rel because it can be followed easily to get more info. 06:08, 30 June 2013 (PDT)
      • I'm happy to draft-up a rel-webmention spec and add it to the HTML5 rel registry if we decide we want this. Also ok with just keeping the URL for now. - Tantek 17:46, 30 June 2013 (PDT)
      • rel=webmention is now registered in the HTML5 rel registry, and points to as the spec. - Tantek 14:32, 13 August 2013 (PDT)
      • Let's have rel=webmention supersede the .org URL value as rel=webmention is shorter, more readable in rel values / HTTP headers, and follows more standard term based rel value naming conventions. - Tantek 21:40, 17 October 2013 (PDT)


Blog posts and articles about webmention:

See Also