Requests to fetch data will accept HTTP GET or POST.

The /login endpoint will insist on being requested via POST for security.

HTTPS will be enforced on production nodes.

Times will be passed as unix timestamps in all cases.

Most methods which handle timestamps have the same requirements and validation, which are:

• "from" (required)
• "until" (optional, will default to now if not specified, if specified must be greater than "from")

A session id will automatically be created for any unauthorized request and passed back in the status of the response as "session_id". A cookie will also be set.

An application using the API should pass back the “session_id” parameter in every request and not trust the cookie to work as the app may not be in the same cookie domain as the API.

The API will look for an existing session id on an incoming request in this order:

1. An HTTP header called "X-Session-Id"
2. A GET or POST parameter called "session_id"
3. A cookie called “session_id”

The API can also authenticate to an organization level (not user level) via a token. Auth token are checked after user sessions, so if you pass both, the user-level login will take preference. If you're logged in as a user and you want to use token authentication, log out first.

This should be passed in a request header as:

X-Auth-Token: 2198b4ce0e9884d44b030397a6395b53

For internal compatibility the token can will also be accepted inside a JSON block sent in POST within the following structure, however this is not guaranteed to be available on all methods, and the header method above is preferable:

{
    "data": {
        "token": "2198b4ce0e9884d44b030397a6395b53"
    }
}

Available Methods

/anomalies

/anomaly

/billing

/exclusion

/image

/js

/login

/match

/metric

/metrics

/misc

/org

/pattern

/patterns

/ping

/signup

/status

/user

/watcher

/watchers