1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in


From snarlwin

Jump to: navigation, search

This is where I will be documenting the SNP 2.0 API

Check back here for updates...



Terminology Used

Throughout this page, "SNP/HTTP" should be read as "SNP 2.0 over HTTP".

Communication Overview

All communication takes place over TCP/IP using port 9887 (native) or port 80 (SNP/HTTP). The port used by Snarl to receive incoming SNP/HTTP requests can be changed from within the SNP/HTTP extension; the port used for native SNP cannot be changed.

Applications using SNP must register with Snarl before attempting to create notifications. The ability to create 'anonymous' notifications via earlier implementations of SNP has been deprecated and is not supported by SNP 2.0. An application may re-register itself at any time, in which case it will receive the same token it previously registered with. Once an application has registered successfully, it can add classes and create notifications.

Key Transport Differences

  1. Native SNP 2.0 allows for feedback responses, SNP/HTTP does not;
  2. Native SNP 2.0 is more efficient for continued communications;

Request Structure

The request structure is slightly different depending which transport medium is used, as follows:

Native SNP

Native SNP 2.0 packets must follow this basic template:

snp://<action>[?<data>=<value>[&<data>=<value>]] CR

Some points to note:

  1. Each request must begin with snp://
  2. Each request must end with a single Carriage Return (0x0D)
  3. Each request must contain an action


snp://reg?id=test/test&title=Test Application&password=password


The URL syntax for SNP/HTTP is very similar to that of native SNP 2.0:



Response Structure

Irrespective of the transport method used, the response format is always the same:

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

<version> The highest version of SNP Snarl supports. As of R2.4, this is always "2.0".

<status code> Identifies the response type. See the 'Status Codes' section.

<description> A human-readable version of the status code.

<data> Additional data provided. Not all requests return additional data, see the actions for more information.




These are the same for all variants, see the Generic API reference for details.

Personal tools