Update Input

The update input component allows you to persist a variable defined inside of the test so that the value will be accessible outside the current scope of the test. Usually, the component is used in conjunction with the set variable component. First, we set a variable. Then, we make it available outside of the current test with the update input component. We pass the update input component the name of the variable that we need to persist outside of the test. The component will first try to update a variable of the same name in the current input set. If that doesn’t exist, it will search for a global variable of the same name. If there is no global variable of the same name, it will check the vault. If the variable doesn’t exist there, it will create one with the same name. Important note: the update input component works only outside of the composer. That is to say, it will only function when a test is executed from the Test List, the Scheduler, or via the API. In the image above, after calling the login endpoint, we have created a variable called access_token with the set var component. Then, we have updated the value with the update input component. In doing so,  the value of the variable will persist throughout and the value can be used in follow-on tests.  

Copy a Test

Here we will show you how to copy and paste a test. Before that, it should be noted that this isn’t often the right way to go. Take a step back and ask yourself if this is actually the perfect solution. We have specifically built our platform to improve work efficiency. Here are some questions that you should ask yourself:
  • Are you looking to do negative testing? You can likely do that in the same test using data sets and the IF component + status codes.
  • Are you looking to run from different environments? No problem with Presets.
  • Do you want to run most but not all of the tests in a specific project? Execute tests using tags. (example, using a unique webhook and the ‘live’ tag.)
If you still wish to copy a test, the procedure is as follows. First, enter the project and test. Then click over to the Published version of the test, then the Copy to Clipboard option becomes available. copy 1 Click Copy to Clipboard and then browse to the Tests view of the same, or another project. There Paste from Clipboard becomes available. copy 2 So here is that entire adventure in video form.

Write Tests in Code

API Fortress has three unique advantages in the market – magic, the visual composer, and the built in assertions/operations. With that said, you are not bound to them exclusively. If you are more comfortable using code, that option is available as well.

Code View

First, the whole test can be seen and edited “naked,” without our glamorous UI. Behind the curtains, the test is described using the XML markup language. To use it, you simply need to look at the top right of the composer. The default is VISUAL COMPOSER, but right next to it is CODE VIEW. Click that. code view - 1 Now you will see the markup language that is the basis of API Fortress.

code view - 2More experienced testers may find this to be the most efficient manner to use the platform. Tip: The best way to learn the markup? Build your tests using the visual composer/magic, then switch to code view and have a look!

A Groovier Approach

Whether you are using the code view, or the visual composer, one important aspect to note is that all “evaluated” fields are actually able to execute a subset of Groovy commands.

For example, let’s take this assertion that verifies whether the “items” element is an array. assert-is Or in code view: <assert-is expression="payload.whatever.items" type="array"/>

Now let’s say you know something more about this array, such as it should always contain more than 3 elements:


Or in code view <assert-greater expression="payload.whatever.items.size()" value="3" type="integer"/>

Notice how in the expression field we deliberately used the size() command to retrieve the size of the object at its left.

Even More Serious Grooviness

Moreover, Groovy can be put within SET components. The first scenario is when you want to set a variable that is not a String. The best way to do it is using the Variable Mode “Object.” The value, in this case, will be evaluated as Groovy code.

set_obj <set var="number" object="otherNumber+50"/>

Here we are assuming that otherObject is a predefined numeric variable. When the SET is executed, the number variable will be an integer. The second scenario is when you want to write extensive logic. Choose the SET component, then choose the item “Language” in the type drop-down (when using Visual Composer), or enter lang=”java” when writing it in Code View.

setOr in code view:

<set var="myVar" lang="java"> <![CDATA[ def item = payload.whatever.items.find { it -> it.id==11 } return item.amount ]]> </set>


What about all the fields that are not explicitly evaluated? Like URL, value, or POST Body? Or the content of a comment? It is often extremely useful to evaluate content on those as well. This is possible using the template syntax. eq <assert-equals expression="payload.id" value="${req_id}"/> This assertion, for example, is evaluating the req_id variable right within the value.

A Little Bit of Everything

Let’s join everything we’ve learned into one snippet:
<set var="data" lang="java">
  def items = payoad.whatever.items.find{ it-> it.id>100}
  return items.collect{ it -> it.providerId}
<each expression="data">
  <post url="http://www.example.com/${counter+1}" params="[:]" var="payload2" mode="json">
   <postBody contentType="application/json">
  <set var="counter" object="counter+1"/>

Want to learn more about Groovy?

Follow this link to the official documentation: http://groovy-lang.org/documentation.html Important Note For security concerns, the cloud version of API Fortress is sandboxed. Meaning many programming language features are disabled. Self-hosted/on-premises eliminates that restraint. While on cloud, if you think a specific feature should be safe to be enabled but is disabled, please contact us and we’ll do our best to help you!

Build an Integration Test (Multistep Test)

One of the core features of the platform is the ability to create proper integration tests. An Integration test is a test in which you examine a complete flow of calls, simulating what an API consumer would experience. Exercising singular endpoints leaves a lot of opportunities for missed bugs and vulnerabilities. Here is a quick guide on how to create one using a token based authentication API. Before getting too deep into the topic, if you log in to your account and go to the “Examples” project, you’ll see a test called “Retail: Integration – Products.” The concept may be easier to understand if you take a look at it first. First, get the token by making your POST call. Name the payload variable “loginPayload.” login Under the login procedure add an assertion named “Set (variable).” Set Var as “access_token,” keep Variable Mode as String, and set Value to “${loginPayload.access_token}” You’ll notice that what we are doing here is specifically taking the access_token variable in the loginPayload response, and setting it as “access_token.” Note: The dollar sign and bracket are necessary when referencing variables. tokenaccess_token Next, make a GET call to your search endpoint. Name this payload “resultsPayload.” This call requires the access token from the login procedure, so we passed it in the header as required for this specific API. We added Header Name as “Authorization” and Value as “${access_token}.” Again, notice the dollar sign and bracket. That is how you reference variables. search Finally, let’s dive into each result from the search payload one-by-one, using the “product id” and the “access token” variables we have set so far.
  1. Add a “for each” assertion and reference the “resultsPayload.products” object.
  2. Add a new “Set (variable)” assertion to set the “id” variable as every single “resultsPayload.product” that is returned. Notice we set the string to “${_1.id}” The system uses _1 automatically when recognizing a subroutine. Makes it easier when things get into many sub levels.
  3. Make a GET to the product details endpoint, using our new “id” variable as the id parameter. Again, you can still reference the original “${access_token}” to make this call. Variables last through the entire test unless overwritten.
each Again, take a look at the integration test in your Examples project, which comes with every account. Remember how many of us learned HTML first by looking at the source of our favorite websites? This is much easier to understand when you see it.

Generate a Status Page

This may be the easiest doc of them all. Generating a status page is as simple as clicking the Gear icon in the top right corner of the page, and going to the Status Pages section. There are two options here. Big Screens automatically refreshes itself, so it works really well for TVs or monitors in a DevOps office, for example. This view is only viewable by users registered to your company. Shareable generates a link that gives a snapshot of the API’s health at the moment the page is loaded. It can be shared publicly without needing an account with API Fortress.
status page
Arrows to the Gear icon and Status Pages section of the Settings page.

Dealing with Authentication (Simple, oAuth, etc)


API Fortress can handle nearly any authorization scheme. Below, we provide some guides on simple ways to work with the most common authorization methods. If it requires usage of a long lasting token, see here for more information.

Simple Authorization

  1. Enter the visual composer
  2. Click Add Component
  3. Click POST (or whatever REST method the authentication server is expecting)
  4. Enter details and then click Add Authentication
  5. Choose Basic
  6. Enter the Username and Password


The header information is automatically encoded and entered for you!


Next, we parameterize the token that we receive in the response.

  1. First, select the Set (variable) component
  2. Next, enter the name that you would like to use for the variable as Var
  3. Enter the value of the token itself as Value
  4. Add a Comment component with the previously set variable as the Value to see the token logged!

From here, we can use the token in follow-on prompts by referencing its variable name.


Here’s the process in video form!

Simple Authorization from the HTTP Client

Using the HTTP composer requires encoding the Username and Password yourself.

  1. Click on Tools > HTTP Client
  2. Click on Tools > Gadgets
  3. Choose base64-encode
  4. Type in the username and password like this with the semicolon “username:password”
  5. Click encode
  6. Copy the generated code (our example is VXNlcm5hbWU6UGFzc3dvcmQ=)
  7. Now use that generated code in your call. Specifically as a Header, and use the word “Basic” under key, and the generated code (VXNlcm5hbWU6UGFzc3dvcmQ=) for value.


That’s it! The call should work now. If not feel free to send us a message at support@apifortress.com!

2 legged, 2-leg

oAuth/Token Exchange

  1. Enter the visual composer
  2. Click Add Component
  3. Click POST (or whatever REST method the authentication server is expecting)
  4. Enter details and add parameters or POST body
  5. In our example its a POST body with username and password

Next, we parameterize the token that we receive in the response.

  1. First, select the Set (variable) component
  2. Next, enter the name that you would like to use for the variable as Var
  3. Enter the reference to the token from the previous payload as Value
  4. Add a Comment component with the previously set variable as the Value to see the token logged!
  5. From here, we can use the token in subsequent API calls by referencing its variable name.

Use Long Lasting Tokens

Introduction It is common for an authentication system to generate long lasting tokens to perform multiple requests. In API Fortress there are many paths of authenticating that can be taken, but sometimes users prefer the token reuse strategy. Goal In this example we are showing you how to allow a test to store a token for further executions, and refresh it when it’s time. Each test will need to contain this logic, and each token will be bound to the test itself. Here’s the complete test. Have a quick look at it before proceeding to the steps:
  1. Prepare the input set by adding the basePath, loginPath, and dataPath. Most importantly, add an empty variable for token and expires. These items will be updated by the test. 1
  2. Add an IF component with this logic:
    !expires || D.nowMillis()>expires.toLong()
  3. Within the IF branch, make the login call. Shown here is a call to the login URL. We are storing the retrieved information in the variable named “loginPayload.” 4
  4. Within the IF branch, set the value to token and expires. Note that in the value we’re saying: take the current time and add one hour
    D.plusHours( D.nowMillis(), 1 )
  5. Within the if branch, update the input set. This is a unique feature of API Fortress. By performing this operation, you’re having the test modify itself for the next use by updating the token and the expires variables. By doing so, the token will be available for all tests executions that will happen within an hour, and therefore no login calls will be made. 7 8
  6. After the IF branch, perform the main call. We can reference the previously updated token. call
Effects When running outside the workbench, two subsequent test executions will look like this: 910 Code View The whole operation might seem a bit annoying to replicate in every test, but the code view and some copy and paste can ease the pain. Note: Keep in mind this is just an example, and the calls are meant to be very simple The following is the code version of the IF branch containing the authentication logic. <if expression="!expires || D.nowMillis()&gt;expires.toLong()">   <comment>     <![CDATA[Authentication has to be performed due to expired token]]>   </comment>   <post url="${basePath}${loginPath}" params="[:]" var="loginPayload" mode="json">     <postParam name="username" value="test"/>     <postParam name="password" value="test"/>   </post>   <set var="token" value="${loginPayload.token}" lang="java"/>   <set var="expires" value="${D.plusHours(D.nowMillis(),1)}"/>   <update-input var="token"/>   <update-input var="expires"/> </if> More Notes Updating input variables won’t work when launching a test from within the composer, so the login call will run every time when developing a test. Run the test from outside the composer or schedule the test to see it in action. Language Appendix Negation: the exclamation mark (!) prior to an expression is used as a negation and it means: when it’s false, when it’s empty, when it does not exist. In our example: !expires means when expires is empty. Logic Or: the classic double pipe sign ( || ). Rarely used in API Fortress except in IF conditions. toLong(): converts a string to a long number. D.<action>() an API Fortress language extension that provides date and time manipulation functionalities. Please refer to https://apifortress.com/doc/expression-language-extensions/ for further details.