Payload formats

There are several ways to transfer the additional data:

GET parameters are probably easiest.
The downside is that you are limited - depending on the web server
software used - to 2048, 4096 or 8192 bytes of header data, which
means that your URL with the parameters even has to be shorter.

POST requests have no limit in size, which is why most
webhook implementations abstain from using GET and
rather send out POST HTTP requests.

application/x-www-form-urlencoded

That's the format browsers send when you submit a simple form on the web.
It was officially
defined in HTML 4.01
and is supported by probably every HTTP client and server.

When receiving such a request, the
Content-Type
header is set to application/x-www-form-urlencoded.

Data in this format are written down like the URL parameters in GET
requests:

Special characters like = and & have to be
percent-encoded, increasing the size of the POST content a bit.

Another issue with this format is that the size increases strongly
when transmitting deeply nested data, because for each attribute, the
full path needs to be submitted again and again:

In this example, addressbook.entries is repeated, and the data path
is actually longer than the values.

You also have to take into consideration that - since the Content-Type header
is always set to application/x-www-form-urlencoded - there is
no standard way of determining which data you get, except by inspecting
the data itself.
So it's not possible to use the web hook endpoint for more than one type
of web hooks.

Examples in the wild

JSON

JSON, defined in
RFC 4627,
is a JavaScript-native readable data serialization format.
It's ideal as light-weight data exchange format between different
programming languages, and especially useful when used in JavaScript
web applications.

Compared to x-www-form-urlencoded, its size only increases linear
for complex nested data structures.

The POST request's Content-Type header can either be set to
application/json or the MIME type of the data that
gets transferred in the payload, e.g.
application/vnd.foo.commithook+json.
By utilizing the Content-Type header, endpoints can reject unknown
and support different payload formats easily.

Validation is a bit problematic, since
JSON-schema is not
finished nor stable (as of 2013-09).
JSON validation tools are only beginning to emerge.

Sending webhook calls

<?php$payload=array('username'=>'dirty.harry','confirmed'=>true,'email'=>'harry@mud.example.org');$context=stream_context_create(array('http'=>array('method'=>'POST','header'=>'Content-Type: application/vnd.example.activation+json','content'=>json_encode($payload))));$response=file_get_contents('http://example.org/handler.php',false,$context);//in most cases we can ignore the response dataecho$response;?>

I'm looking for a new job.
If you can recommend a company in Leipzig/Germany that's looking
for a PHP developer, please
drop me a mail.