Send API Requests

Introduction

The Send API Request action allows you to send API requests for both Web Tests and Mobile Tests.

Structure

The following HTTP request methods are available:

  • GET
  • POST
  • PUT
  • DELETE
  • HEAD
  • PATCH

The Send API Request modal has 5 tabs:

  1. Params
  2. Authorization
  3. Headers
  4. Body
  5. Response

The Response tab has 5 sections:

  1. Status
  2. Body
  3. Cookies
  4. Headers
  5. Duration

The Send button allows you to test the API request and see the output in the Response section.

Since this preview is done in the frontend, the API request will be sent with AJAX.

But when you actually execute that test, the API request will be sent with Python.

This means that the Send API Request action will work for both Web Tests and Mobile Tests.

Adding variables

You can use variables in the API Request.

Simply typing $ inside an input will display a dropdown with the available variables.

You can concatenate variables with strings or with other variables by placing the variable name between double curly brackets:
My name is {{$username}} and my email is {{$email}}

You can also store the output from the Response section in variables, by using the Store in variable option.

This allows you to chain requests and pass values from one Send API Request step to another.

If you need to extract values from JSON objects or arrays, you can use the actions from the Endtest Utilities.

Since the variables are created only when you execute the test, they won't be available when you test the API request by clicking on the Send button.

Sessions and Cookies

If you have multiple Send API Request steps in a test execution, the requests will use the same session.

That means the cookies generated by a Send API Request step will be automatically included in the next Send API Request steps from that test execution.

In case you want to clear the session, you can use the Clear API Session method from the Miscellaneous action.

The session and cookies from the Send API Request steps are separate from the session and cookies from the browsers and mobile apps.

The API requests are not sent through the browsers or the mobile apps.

Cookies generated by Send API Request steps will not be automatically placed in the browser, but you can transfer them to variables and place them in the browser with Execute JavaScript steps.

Sending files

You can also send a file with a Send API Request step.

The file download link must be added in the Value cell.

A variable containing that file download link can also be used.

Files can be stored in the Endtest Drive, but you can also use other file storage systems.

The Description for that row must be file, otherwise the test won't know that it needs to download the file and place it in the request.

Here's an example for sending a file to our own Endtest API:

endtest send api request file

If the Description does not have the value file, the row will be processed as having a file download link, and not a file.

Common errors and solutions

1. Missing Headers

In some situations, the endpoint that you are calling expects certain headers.

If your API request isn't getting the expected response, add the following items in the Headers section:

KeyValue
Content-Typeapplication/vnd.api+json
Cache-Controlno-cache
User-AgentEndtest

When you click on the Send button, the API request is sent through your browser. This might cause certain headers (such as the User-Agent) to be overwritten by your browser.

When you execute the test, the API request is sent by a Python script from the machine on which the test is being executed. This means that no headers will be overwritten.

If you're not getting the expected response when you click on the Send button, try to execute the test and see if that gives you the expected response.

2. Restricted Access

When you execute a test which contains a Send API Request step, the API request will be sent from one of our IP addresses.

If you're getting a HTTP status code like 404 (Not Found) or 403 (Forbidden), check if you need to whitelist our list of Secure Gateway IP addresses:

Secure Gateway IP Addresses
34.211.40.72
35.166.159.89
207.254.40.71
207.254.60.102
52.89.18.176
52.26.12.35
54.187.169.42
52.43.87.222
34.214.85.4
54.184.162.15
44.237.178.201
44.238.105.245
44.228.22.115
35.81.185.74
207.254.52.64
44.241.213.227
52.26.206.66
52.13.40.64
44.238.190.158
207.254.60.6
207.254.41.137
207.254.60.76
34.213.62.124
54.191.53.140
18.237.140.182
52.11.28.247
44.240.94.219

If you want to use Real IP Geolocation in your tests, you'll have to add these entries to the whitelist as well:

GeolocationIP Address
San Francisco, US52.53.118.130
Seattle, US20.64.225.137
Montreal, Canada3.97.155.50
London, UK3.9.107.187
Frankfurt, Germany52.28.171.236
Eemshaven, Netherlands34.90.84.125
Dubai, UAE3.28.26.211
Tel Aviv, Israel51.16.199.215
Tokyo, Japan18.179.93.49
Seoul, South Korea13.209.174.252
Singapore54.151.171.44
Sydney, Australia54.206.130.168

3. No response in the Results

When you execute a test which contains a Send API Request step, the test execution logs will only contain the Status and the Body from the response if you selected the Store in variable action in the Response tab from the Send API Request modal.

4. Cross-Origin Resource Sharing (CORS) errors

Browsers use CORS in APIs such as XMLHttpRequest or Fetch to mitigate the risks of cross-origin HTTP requests.

When you click on the Send button from the Send API Request modal, the API request is sent through your own browser.

That means you might encounter CORS errors when doing that.

But when you run the test, the API request doesn't go through the browser, that means that you won't encounter CORS errors when running the test.

← Data-driven TestingRead SMS →