The public API open to the users. [Read the docs and learn more.](https://threatjammer.com/docs). ## General information ### Description Threat Jammer supports two end-user REST APIs: the User API and the Report API. The end-user uses the User API to interact with the different databases, heuristics, and machine learning processes. Devices use the Report API to interact with Threat Jammer. This document will explain how to use the User API and interact with the different services, create a token, interpret the quota information, and create the HTTP request to interact with the User API. ### Authentication The API is protected by a **Bearer authentication** schema. **Bearer authentication** (also called **token authentication**) is an HTTP authentication scheme that involves security tokens called bearer tokens. It is used to authenticate the user. All the different endpoints expect a `Bearer` token in the `Authorization` header. Example: ``` curl -X 'GET' 'https://dublin.api.threatjammer.com/test' -H 'accept: application/json' -H 'Authorization: Bearer YOUR_API_KEY' ``` You can obtain a token after registering on the [ThreatJammer.com](https://threatjammer.com) website for free. ### Region specific tokens All the `Bearer` tokens contain information about the authorized region. The developers have to use a token created for the region they want to use. A token used in a different region will return a `401 Unauthorized` error. ### Global errors The API will return the following permanent errors: - a `401 Unauthorized` error if the token is not valid, or does not belong to the region. - a `401 Unauthorized` error if the token does not exist. - a `401 Unauthorized` error if the token is malformed. - a `403 Forbidden` error if the subscription level is not enough. Some endpoints are only available for paid subscription levels. And these temporary errors: - a `429 Too Many Requests` error if the quota is exceeded (see below). ### Quota limits **Every request to the User API will consume one (1) quota point.** The API has two rate limiting processes: - a quota limit of **5000** requests per month for the `FREE` account. The limit is reset every month. - a quota limit of **10** requests per minute for the `FREE` account. The limit is reset every minute and implements a sliding window mechanism.

Welcome to TruAnon! Thank you for helping make the Internet a safer place to be. Adopting TruAnon is simple. There is no setup or dependencies, nothing to store or process. Making identity part of your service is fun, and you’ll be up and running in a matter of minutes. TruAnon Private Token is used anytime you request information from TruAnon and you must edit this into the Variables section for this collection. This API contains two endpoints and both require these same two arguments, also found in the Variables section of this collection. These two arguments are: TruAnon Service Identifier and Your Member Name Your TruAnon Service Identifier was provided by TruAnon and is likely the root domain of your site or service. Your Member Name is the unique member ID on your system that you would like to query. Information is continuously updated for display purposes and aside from performance considerations, there should be no need to capture or save anything from TruAnon.

The Turbine Labs API provides CRUD operations for core object types, and is mostly RESTy. The easiest way to interact with the API is with [tbnctl](https://docs.turbinelabs.io/advanced/tbnctl.html). If you want to make direct HTTP calls, however, you can obtain an access token using tbnctl, and then pass it in the Authorization header, prefixed by `Token `: ```console curl -H "Authorization: Token " https://api.turbinelabs.io/v1.0/cluster ```

# Overview The Fitbit Plus API is a RESTful API. The requests and responses are formated according to the [JSON API](http://jsonapi.org/format/1.0/) specification. In addition to this documentation, we also provide an [OpenAPI](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md) "yaml" file describing the API: [Fitbit Plus API Specification](swagger.yaml). # Authentication Authentication for the Fitbit Plus API is based on the [OAuth 2.0 Authorization Framework](https://tools.ietf.org/html/rfc6749). Fitbit Plus currently supports grant types of **client_credentials** and **refresh_token**. See [POST /oauth/token](#operation/createToken) for details on the request and response formats. ## Building Integrations We will provide customers with unique client credentials for each application/integration they build, allowing us to enforce appropriate access controls and monitor API usage. The client credentials will be scoped to the organization, and allow full access to all patients and related data within that organization. These credentials are appropriate for creating an integration that does one of the following: - background reporting/analysis - synchronizing data with another system (such as an EMR) The API credentials and oauth flows we currently support are **not** well suited for creating a user-facing application that allows a user (patient, coach, or admin) to login and have access to data which is appropriate to that specific user. It is possible to build such an application, but it is not possible to use Fitbit Plus as a federated identity provider. You would need to have a separate means of verifying a user's identity. We do not currently support the required password-based oauth flow to make this possible. # Paging The Fitbit Plus API supports two different pagination strategies for GET collection endpoints. #### Skip-based paging Skip-based paging uses the query parameters `page[size]` and `page[number]` to specify the max number of resources returned and the page number. We default to skip-based paging if there are no page parameters. The response will include a `links` object containing links to the first, last, prev, and next pages of data. If the contents of the collection change while you are iterating through the collection, you will see duplicate or missing documents. For example, if you are iterating through the `calender_event` resource via `GET /pub/calendar_event?sort=start_at&page[size]=50&page[number]=1`, and a new `calendar_event` is created that has a `start_at` value before the first `calendar_event`, when you fetch the next page at `GET /pub/calendar_event?sort=start_at&page[size]=50&page[number]=2`, the first entry in the second response will be a duplicate of the last entry in the first response. #### Cursor-based paging Cursor-based paging uses the query parameters `page[limit]` and `page[after]` to specify the max number of entries returned and identify where to begin the next page. Add `page[limit]` to the parameters to use cursor-based paging. The response will include a `links` object containing a link to the next page of data, if the next page exists. Cursor-based paging is not subject to duplication if new resources are added to the collection. For example, if you are iterating through the `calender_event` resource via `GET /pub/calendar_event?sort=start_at&page[limit]=50`, and a new `calendar_event` is created that has a `start_at` value before the first `calendar_event`, you will not see a duplicate entry when you fetch the next page at `GET /pub/calendar_event?sort=start_at&page[limit]=50&page[after]=`. We encourage the use of cursor-based paging for performance reasons. In either form of paging, you can determine whether any resources were missed by comparing the number of fetched resources against `meta.count`. Set `page[size]` or `page[limit]` to 0 to get only the count. It is not valid to mix the two strategies.

Api Documentation

A client for issuing REST requests to the Azure Batch service.

The Graph RBAC Management Client

Our API documentation has been moved to https://docs.zenoti.com.