Legacy Documentation
You're viewing legacy documentation for API Fortress (deployed via an on-premises container). To view documentation for the new SaaS version of API Fortress — now known as Sauce Labs API Testing and Monitoring (with Sauce Connect tunnels) — see API Testing on the Sauce Labs Cloud.

API Fortress – Using the v2 API (deprecated)

Preamble

API Fortress exposes most of its functionalities via an API to allow automation and scripting. For example, you can trigger a test to automatically execute during a Jenkins deployment. Use of the API is available to all paid accounts. Please email info@apifortress.com to get setup. The scope of this document is providing an overview of the endpoints. Two versions of it are currently coexisting:
  • default – where most functionalities currently reside on.
  • v2 – which implements the new “test API.”

Authentication

The authentication flow for the API is fairly simple. 1. Using the company settings dashboard, generate a key and secret pair. add key 2. While making a request to the API, create a token by applying the following algorithm:
md5(key+secret+epoch)
where “epoch” is the Unix time. 3. Add the following headers to the request:
X-Key : <your_api_key_here>
X-Token : <your_generated_token_here>
Remember that tokens are very short lived and should be generated for each request.

default : /api/rest/company

Actions related to the company profile.
  • GET /details : provide details for the current company

Default : /api/rest/event

Provides access to the event objects.
  • GET /list/{projectId} : lists out all the events of the last week for the given project.
  • GET /details/{eventId} : provide the details of the event with the given id.

Default : /api/rest/monitor

Provides access to the metrics objects.
  • GET /list/{projectId} : lists out all the metrics events of the last week for the given project.

Default : /api/rest/schedule

Provides access to the scheduler data.
  • GET /byTest/{testId} : lists all the scheduler settings for the given test.
  • GET /byProject/{projectId} : lists all the scheduler settings for the given project.

V2 : /api/rest/v2/test

Controls a number of test interactions.
  • GET /list/{projectId} : lists all the tests for the given project.
  • GET /details/{testId} : provides details for the given test.
  • GET /statuses/{projectId} : tells whether the latest execution of each test for the given project succeeded or failed.
  • POST /run/{testId} : runs a test, possibly against a provided payload. The body of the post depends on the options set in query params:
    downloader optional if the test has to retrieve certain resources then you might want to choose which downloader is going to be used. If not set, the default will be used.
    silent optional if set to “true” the test will not trigger any alert.
    dryrun optional if set to “true” the result of the test will not be saved.
    sync optional if set to “true” the test will run a foreground process and will return the result of the test.
    nosets optional if set to “true” the test will ignore the input sets and run the unit only once (typical when the payload is provided).
    mode required can either be “payload” or “serializer.”
    Payload Mode
    When set to “payload” mode the required POST body will look like this:
{
  "Content-Type": "application/json",
  "payload": "{\"success\":true,\"data\":[\"one\",\"two\",\"three\"]}"
  "params": { "server": "15a" }
}
Content-Type: is the content type of the “payload” being forwarded. payload: is the body of the payload to be tested. In the test, it will be referenced as the variable “payload.” params: extra parameters you might want to make available to the environment. In the test they will be available as variables. Note: if you want to run a test without payload forwarding you can send an empty object.
Serializer Mode
The serializer mode allows an agent to send full “request and response” serializations to the API Fortress engine. See [Serializer] for more details.
  • POST /runAutomatch/{projectId} : runs multiple tests inside a project, based on the automatch strategy. See [Automatch] for more details. The options are pretty much the same for the previous endpoint:
downloader optional if the test has to retrieve certain resources then you might want to choose which downloader is going to be used. If not set, the default will be used.
silent optional if set to “true” the test will not trigger any alert.
dryrun optional if set to “true” the result of the test will not be saved.
nosets optional if set to “true” the test will ignore the input sets and run the unit only once (typical when the payload is provided).
mode required can either be “payload” or “serializer.”