Once the Linked Process has been build it's time to test the Process. When it comes to testing API Linked Processes there are couple of methods we can use. First and the easiest method is to add a Manual Trigger to the Process and run it with that. This is possible if the API Trigger expects payload in the HTTP body. However in this case when we have the value we need inside the URL as a query parameter, the testing needs to be handled with other ways. Be sure to name the Manual Trigger's parameter as "httpBody". This enables you to use the reference #trigger.data.httpBody regardless of the Trigger.

Testing a Linked Processes can be done by using a third party tool like Postman to send a HTTP request to the endpoint. The base URL depends on the Agent Group where the Linked Process and the API has been deployed. You can check the base URL from the Agent's settings page. PaaS Agent's usually have the base URL set as follows:
​

https://{agent-name}.frendsapp.com:443/

http://{agent-name}.frendsapp.com:80/

As you can see there are specific base URL's for HTTP and HTTPS calls. You need to check which HTTP protocol is enabled in the API specification and in the Linked Process.

Frends doesn't offer much more tools for testing the API processes or the whole API structure, but luckily there are variety of third party API testing tools and service providers which can offer you testing capabilities for your API. Here are some examples which you can use:

SmartBear

ACCELQ

Errors are part any development process including when implementing Frends API endpoints. Everybody makes mistakes and it's usually good thing because it helps everybody to develop themselves. When implementing Frends API endpoints some errors are bound to happen. In this module we will look at some of the most usual errors and how to debug them in Frends.

One most usual error relates to the HTTP method used in the request. When testing your API with a Postman or other tool you may get 400 Bad Request responses. In this case the response message will give you a hint what would be the leading cause for this error.
​

"Invalid scheme used for call. Use http:///api/f44_demo/GetProduct_v1?prod_code=4"

This relates to the fact that the request tried to use HTTPS on a HTTP endpoint. Switching you request method to a HTTP or changing the API schema and process's Allowed methods To HTTPS or both will fix this issue.

Another reason for this 400 Bad Request response might be invalid or missing query or path parameter. To debug the issue you can check that you have set the path/query parameter correctly or change the required attribute in API specs to false.

Unauthorized response could be caused by couple of reasons. If you have set an API key to be used in the API endpoint, make sure that the same key is added to you request. In Postman you can easily set the API key in the Authorization tab. Just copy the key from Frends API Keys view and add it there.

Other reason for this kind of response might be inside the Process itself. There is no actual whitelisting which can be done in Frends but you can use for example a decision element to check the caller's IP address and throw an exception from the Process with this kind of response if it's not the correct one. This functionality can be achieved with use of Environment variables.

The next article is Introduction to Deploying APIs and API Version Control.