Anura Docs

Anura Reporting API - Integration

The Anura Reporting API allows you to access Anura reports data from within your own applications. To get started, you will need to create a reporting API token.

Anura Reporting API - Integration - API Tokens

You can create and manage Reporting API tokens by logging into the Anura Dashboard and going to the "Reporting API" token management interface, located within the "Account" section of the navigation menu, or by visiting https://dashboard.anura.io/api.

Create Reporting API Token Form Fields

Managing Reporting API Tokens

• Reporting API tokens may be temporarily enabled or disabled.
• Reporting API tokens may be permanently removed.
• As of June 06, 2019, Reporting API tokens are bound to the user account that created them. If the creating user's account is disabled, all of their corresponding tokens will also be disabled.

Anura Reporting API - Integration - Performing Requests

Requests to the Anura Reporting API are made over secure connections using the HTTP POST method.

Things to Remember...

• POST parameter string values must be URL encoded.
• Drilling into metric reporting data will require optional parameters to be set.
• Some drilldown parameters require that a parent parameter be applied first.
• A daily breakdown will be returned when all applicable drilldown parameters have been applied.
• Instance, source, and campaign interface parameters may be applied at any time.
• "All Instances", "All Sources", and "All Campaigns" are acceptable interface values where applicable.
• Anura reporting is based on the Coordinated Universal Time (UTC) time zone.

Limitations

Date specific API requests are limited to a 7-day rolling time frame with the exception of "Overview" endpoints, which have a 31-day rolling time frame. If your request falls outside of the time frame limit, a HTTP status code of "400 - Bad Request" will be returned. See Reporting API: Handling Responses for more details.

Anura Reporting API - Integration - Handling Responses

Responses from the Anura Reporting API are JSON encoded and typically returned within milliseconds. However, in cases where vast amounts of unique data exist, responses may take several seconds or minutes. Please be sure to adjust any timeouts to wait until the response has been returned.

There are 5 distinct HTTP status response codes that may be encountered when performing requests. The following table provides HTTP status codes with a brief description of their meaning:

Things to Remember...

• String response values are returned URL encoded.
• Script and Direct "instance" table values are returned as a URL encoded object containing both the "id" and "name" of the instance.
• Script's "adblocker" value may return "null" when ad blocker detection is not enabled for your instance.

Anura Reporting API - Integration - Summary Filters

Summary filters enable the further refinement of Anura Reporting API data, allowing only results that match the provided constraints to be returned.

Filter Groups and Filter Objects

Summary filters are structured as an array of one or more "filter group" arrays containing "filter objects."

• Filter objects are used to provide constraints for your query, each defining their own column, operator, and value.
• Filter groups allow for multiple sets of constraints to be applied at the same time.
• Filter groups are combined using OR statements while each filter object in the group is combined using AND statements.

For example, if you want to return only sources from a Script sessions endpoint having greater than 5,000 requests, you can create a single filter group array containing one filter object.

[
    [
        {
            "column": "requests",
            "operator": "greater_than",
            "value": 5000
        }
    ]
]

WHERE (requests > 5000)

To further the example, of the sources returned, you want to view only sources whose rate of good traffic is less than or equal to 30%. In this case, you would create a single filter group array containing two filter objects.

[
    [
        {
            "column": "requests",
            "operator": "greater_than",
            "value": 5000
        },
        {
            "column": "good_rate",
            "operator": "less_than_equal_to",
            "value": 30.00
        }
    ]
]

WHERE (requests > 5000 AND good_rate <= 30.00)

To go even further, you also want to include sources having greater than 2,000 responses whose warning rate is greater than or equal to 80%. To accomplish this, you would create two filter groups, each containing two filter objects.

[
    [
        {
            "column": "requests",
            "operator": "greater_than",
            "value": 5000
        },
        {
            "column": "good_rate",
            "operator": "less_than_equal_to",
            "value": 30.00
        }
    ],
    [
        {
            "column": "responses",
            "operator": "greater_than",
            "value": 2000
        },
        {
            "column": "warning_rate",
            "operator": "greater_than_equal_to",
            "value": 80.00
        }
    ]
]

WHERE (requests > 5000 AND good_rate <= 30.00) OR (responses > 2000 AND warning_rate >= 80.00)

There are no restrictions to the number of filter groups or filter objects you can use to filter your summary data. However, be mindful not to apply too many constraints as the result set may be reduced in an undesirable manner.

Applying Summary Filters

Summary filters can be applied by passing a pre-saved filter ID, or an "on the fly" array of filter objects, to Script endpoints and Direct endpoints using the filters POST parameter.

All tabular Script and Direct summary data returned by the Anura Reporting API can be filtered. However, there are a few things to be aware of...

• The first column in a summary data table is a string referred to as the "primary key".
• Rate columns and Rule Set columns will always be returned when filtered, regardless of display preference.
• Columns not available for specific reporting endpoints will be ignored, while also having a conflict message returned.

Script Columns

The following columns can be used when filtering Script summary data.

Direct Columns

The following columns can be used when filtering Direct summary data.

Summary Filter Operators

Operators are the comparison mechanism(s) used when filtering summary data. String values have a different set of operators than integers and floats, which are shown in the following table.

Summary Filter Conflicts

A summary data filter conflict can occur when a constraining column is unavailable for the requested endpoint. When a filter conflict occurs, the column will be ignored, and a conflict message will be returned in the query response data to make you aware that the constraint was not applied.

For example, performing a query to the Script: Pages endpoint using a summary filter that contains the requests column, which is not available on the Pages endpoint, will result in a filter conflict.

"query": {
    "start": 20261001,
    "end": 20261007,
    "instance": 123456789,
    "source": false,
    "campaign": false,
    "host": false,
    "path": false,
    "filters": [
        [
            {
                "column": "requests",
                "operator": "greater_than_equal_to",
                "value": 100,
                "conflict": "Column%20not%20available"
            },
            {
                "column": "responses",
                "operator": "less_than_equal_to",
                "value": 1000
            },
            {
                "column": "good_rate",
                "operator": "less_than",
                "value": 76.54
            }
        ]
    ],
    "chart": true,
    "rates": true,
    "rules": true,
    "search": false,
    "startswith": false,
    "sort": "1:desc",
    "page": 1,
    "limit": 20,
    "results": 1,
    "pages": 1
}