Quick Start Guide – Easy Proof of Concept Steps

Welcome to your API Fortress trial!

You should have received an email with your login credentials from the platform. If you haven’t please email us (support@apifortress.com).

The links below are resources that will help you quickly and easily stand up example tests. If you have questions please feel free to reach out. If you prefer video guides they are here: Youtube or Vimeo.

Simple 3 Phase Evaluation

Phase 1

Phase 2

Phase 3

More Information

All Video Guides: Youtube or Vimeo

Example public APIs to play with:
Retail API
Uber API

Please let us know if there is anything else we can do to help with the evaluation process.

Schedule a Test


Scheduling is another unique and powerful aspect to API Fortress. We make it simple to schedule a test to run as often as you like, from any location you choose (based on account type), and with great granularity as to when it runs. Let’s show you how it can work.

Step 1: Publish the Working Copy

API Fortress has a unique working copy vs published system to allow you to edit tests without effecting the live tests. You can learn more about it here. Step 1 is to publish your draft into a working copy.

Step 2: Schedule

Click Schedule button.

Step 3: Create a New Schedule

Click Create New Run button.

Step 4: Fill Out the Fields

Name – As it states, this is just to see a name on the schedules list. We suggest having it make sense like “United States East, Every 5 Mins.”
Note: the run won’t trigger when the test is paused.

Downloader – This dropdown allows you to choose from which datacenter the resources should be retrieved from.

Try a second execution – When this checkbox is selected, another execution will be run after 2m 30s if the initial execution fails. 

Time configuration – This section allows you to choose in which minutes of the hour, which hours of the day, which days of the month, and which months of the year the test is going to run. This is unique in that it gives you the granularity to do things such as schedule executions around things such as a weekly scheduled deployment.

Variable Override – This is another unique feature of API Fortress. This section allows you to override any variable that is defined in the global or data set sections of the test. One easy example is to create a new run that executes in the morning and late afternoon where the variable you override is the domain. Therefore, twice a day the staging environment is tested.

Create a Test Quickly


API Fortress is focused on API Quality. That means performance, uptime and accuracy. That last part is where we really differentiate ourselves. The metrics of an API call are important, but what we do better than anyone is help verify the logic of the API. It is more than schema validation, and requires zero coding.

Below we will show you how to quickly create a test using an e-commerce API.

Let’s get started!

Step 1: Create a Project

When you first login, you are introduced to the Company Dashboard. The company already contains a project called Examples with some example tests. Click Create Project.

Step 2: Create a Test

Step 3: Choose Your Test Creation Method

Once you have named your test you will be redirected to the Interstitial page. There are two avenues to take in building a test. API Fortress is really good at building a test draft for you. First you must decide if you want to build a test manually, from a Spec File, an Apiary account, or using the tool we call Magic. Since this is a quick start guide, we will show you how to use Magic. To build using a Spec file see http://apifortress.com/doc/build-from-spec/, or from an Apiary account see http://apifortress.com/doc/build-from-apiary/.

Step 4: Create a Test Using Magic

Click on Compose.

Next, you will be presented with an introduction to the Visual Composer. The final screen of the introduction provides you with more instructions on how to create a test. Close the introduction and open the Console by clicking on HTTP Client button in the left panel.

For this example we will use our own test API. It’s a simple GET, so you can leave the dropdown as it is and enter the following url:

Once done, click the Send button and the response payload will appear.

Now, click the Magic Wand icon at the top right corner of the Console to launch the Magic tool.

The following screens will allow you to choose whether you want to create the input set based on the data provided in the request, and if you want Magic to generate the assertions. The final screen summarizes what was done. Press Continue on each screen.

We call it a draft because you should take a moment to verify each object, and/or add more logic to it. API Fortress has a lot of tools that allow for comprehensive continuous integration testing. Magic is great at understanding datatypes and structure, which is often 90% of the work. For an example of adding more intelligence to a test see the Appendix at the bottom.

All Done!

Learn how to schedule a test here.
Learn about data and notifications connectors here. Simple solutions to plug APIF into the systems you use today (like DataDog or New Relic).

Appendix: A Smarter Test

Furthermore, you could want to add more intelligence to the test to truly verify its accuracy. Let’s consider, for example, a scenario where the following snippet of the payload is present only certain times:

“shipping”: {
“modes”: [“fast”,”regular”],
while the payload often contains this snippet:

“shipping”: {
        “available”: false

Since the “modes” and “zones” are present only when “available” is true, we could add an IF condition that differentiates the two different scenarios.

Select the assertion (as shown above), then click on the three green dots on the left of that assertion. Choose ‘add component after,’ select the ‘IF’ component, and then type in the “field” this code: payload.content.shipping.available==true

Then, drag and drop the following two assertions (“modes” and “zones”) inside the IF component. Now, those assertions will only be executed when “available” is true.

That is one of many examples of the flexibility and power of API Fortress. Nest GET statements together, use the WHILE or EACH component. Almost anything you can think of can be done.

Build from Spec (Swagger / Open API / RAML)

This feature allows you to create a test starting from a specification file.

From the interstitial page choose the ‘Build from SPEC’ icon.

Note: the process deletes your working copy, keep it in mind if you are doing it on an existing test.

The available specification files you can choose from are: RAML 0.8, RAML 1.0, Swagger, API Blueprint, I/O Docs.

There are two ways to do it: uploading a File or an URL. The dropdown on the top right of the screen allows you to choose your mode.

The File can be uploaded by dragging it in the dedicated area or clicking on it and upload the file from your computer.

Or you can reference it with a URL. Selecting the URL field in the dropdown shows up the SPEC Url field.

Once you have chosen the file type and the method, click the Save button and you will be redirected to the next step where the available endpoints are listed in a dropdown. Choose the one you want to test and tap Continue. That’s all, test will be created. Now you can make any adjustment, save and publish it for being able to schedule it.

Note: For RAML we suggest uploading the entire zip file. Here is an example video of building from a RAML file.

Writing Your First Test

The easiest way to write your first test is using the tool we named Magic. To put it simply, with Magic you can make an API call and then it will automatically create a test based on the payload.

First of all, you need to make an API call with the console. For this example we are using our own test API:


Type in the URL and then press the Send button.

Next, tap the magic wand icon at the top right corner of the Console to launch the Magic tool.


The following screen will allow you to choose whether you want to create the input set (based on the data provided in the request) or skip it. Press Continue.


The next screen, allows you to choose if you want to create the assertions. You do, so press Continue once again.


At the end you will see a report about the applied changes.


Here is the result: a fully working draft of an API payload test.


Now, you can launch the test and see the report….


Tests are meant to validate an endpoint, so it makes a lot of sense to add more input sets and have the unit run against them.



Magic is able to understand basic things based on a single request and response. Refining it is mostly about transforming vague assertions to be more specific.
For example, we know that payload.content.options.mainColor can be a finite number of values. Therefore, using an “assert exist” assertion is a bit poor…


So let’s change it to an “assert in” that verifies the field value to be either “red” or “black_plain.”


Done! Your first test is ready to be scheduled now.