SNP 2 enhances SNP 1 with a much easier request structure, dropping the need for awkward separator characters and introducing a more familiar URI-approach.  Additionally SNP 2 provides extensibility in that the request structure follows the Win32 transport format, giving access to the full Snarl API.

Message Structure

Request Structure

An SNP 2 request begins with the header snp:// and is terminated by a single \r (aka CR, Chr(13), 0x0D…):


Each entry must contain a key and value; valueless keys are not permitted.  Case is also important.  Other than that, each SNP 2 request follows the standard Snarl API format.



Response Structure

A SNP 2 response is a single line of information separated by forward slashes:

SNP/<version>/<status code>/<status text>[/<data>]

Version is the latest version of SNP 2 supported by the Snarl instance that communications are taking place with.  Communications with Snarl typically take place using an agreed protocol on an agreed port – there is currently no concept of a client being able to ‘version up’.  A client can determine what version of SNP is available on a certain port by issuing the [version] command, which will return a version-specific SNP error message.



Further Reading


SNP2 does not support subscriptions or notification forwarding.  Attempting to issue a [subscribe] request will result in an error – typically BadCommand, although this may vary depending on individual implementation.


SNP/HTTP is a variation of SNP 2 that can be used via a web browser.  The syntax is the same, however the snp:// prefix is replaced with the traditional http:// prefix, as follows:

http://localhost/notify?title=Hello, world!

Note that while SNP/HTTP defaults to port 80, the port can usually be changed – again, this depends on individual implementation.

Unlike SNP 2.0, SNP/HTTP is not deprecated and development on it continues.