The Digivante REST API is designed to provide you with a programmatic method to create and manage your tests, define & execute test runs, and retrieve their results. This interface support common use cases such as using the Digivante Community regularly for regression scenarios in CI/CD deployments, or pushing tests to the Digivante community via project or test management tools like JIRA. The API usage scenarios cater for using test run results as a blocking state for builds and/or to load into reporting systems.
An API is an application programming interface. It is a set of rules that allows programs to talk to each other. Developers create APIs which run on a server, and it allows clients to talk to it and pass information.
REST stands for Representational State Transfer. It is a design pattern for an API which sets rules as to how it functions. For instance, one rule states that you should be able to get a piece of data (a resource) when you link to a specific URL. Each URL is called a request, while the data returned to you is called a response. As all REST API must follow a standard set of architectural constraints, third parties have a strong expectation of how an API will function, and how to integrate it into their for the own usage.
The API uses API keys for authentication. Authentication is handled client side. The client has to send authentication details to various endpoints such as POST /v1/test-cases. These are sent via a X-API-Key header. These keys are long living and do not expire unless requested to be regenerated.
To obtain a key, contact your Digivante account manager & your account will be setup for API use and a key will be provided.
The API itself is accessed securely, that is, using HTTPS.
The API has a global rate limit of 180 requests per minute. In addition to this, the test runs endpoint uses a concept called “executions” to define how much testing an API user can perform in a given period.
When executing tests via a test run, users can define the test run parameters via a filters concept. Filters define which devices the user wishes their test cases to be tested upon. The /v1/filters endpoint provides details on the available filters. Once defined in a test run, each test case-filter combination counts as an execution. Should a test run have multiple filters, for each constituent test case, each filter will count as an additional execution.
For example, a test case within a test run with two filters: “Mobile devices”, and “Tablet devices”, will count as two executions. The benefit to this level of granularity is that there will be two separate set of results to analyse, which provides a greater degree of confidence.
Note: There is a filter which can be set which does not define any specific devices to be tested. This filter is intended for use when the device information is not important to the nature of the testing and should usually be used on its own. It is possible to create a test run with this, and in combination with some or indeed, all specific filters. This configuration decrements the execution count in the same manner as usual, but the results for executions using the non-specific filter will also be exhibited for executions using the specific filters. This essentially created duplicates and will not provide additional value.
The execution count has a maximum number per day, as well as during a 30-day period.
The /v1/test-runs/executions-available endpoint provides a method to check the available executions. Common use-cases are to integrate this API call and, prior to starting a test run, assert if the number of test case-filter combinations is equal or less than the available execution count.
The count of executions is defined on a customer-by-customer basis according to your needs. Contact your Digivante account manager for further information.