You can always test endpoints before making them live for your users. We recommend that before you move to test an action or completing any other activity type, you should test all the respective endpoints so everything works properly.
Incoming Endpoints cannot be tested yet.
Endpoints are the building blocks of integrations. They are the URLs, where the communication between the apps takes place. The endpoint response can be regular or paginated. Learn more about normal as well as paginated endpoints and how they are created using our app. In this article, we’ll talk about testing both types of endpoints.
Testing a regular Endpoint
Let us say you have implemented your app, Basecamp through web app. To execute one of the actions you have created an endpoint that fetches the list of Basecamp projects from the connected user account.
The Basecamp API docs, say we will send a GET call, that returns an array of projects to us. After providing the required details for the endpoint, like Request URI, Request and Response Templates, Headers etc (learn more, here), you can test it. Before you save the endpoint at the bottom of the page you can view a Test Endpoint button as shown below.
Click the Test Endpoint button. A Test Interface will appear in front of you as shown below.
To send a test call to Basecamp for the endpoint, you need to provide the following details first:
Authentication Type: The authentication type the endpoint will use
Connected Account: The Basecamp (in this case) user account
The JSON editor requires input that you need to send along the request URL i.e. as query parameters, request body parameters, headers etc. It supports both raw JSON and JSON editor. The Twig variables requestBody, requestBody.data, machine names of activity fields, query, header etc. all are available to this editor.
From the Basecamp documentation, it is evident that in order to fetch the project list we need to specify the account ID in the URL. We will provide the account ID through the editor as shown below.
JSON input editor code
How do we get the account ID value?
In another tab, open the endpoints you have implemented using our web app. First, send a test call of the endpoint that returns the list of accounts. From the Basecamp API docs, we know we need to make a GET call with no parameters attached. So, we send the test call without writing anything in the JSON editor.
Note: If the request you are about to send does not need any headers, query parameters or request body parameters, leave the JSON Input Editor empty and make the call.
Success or Error Message
When you send the test call, at the bottom of the form the status of the call along with a message is displayed. It tells, whether the call sent was successful or not. It can display both success or error message.
You can view the details of the test call sent by clicking the View Details button at the right side. The request and response details will appear as shown below.
Let us discuss what the individual fields are about, below.
Request URI: Displays the URL that was called as a result of this endpoint
Parsed Request: Displays the structure of the request body
Request Headers: The headers that were attached along the request, depending on the app (Basecamp in this case) documentation
Response Headers: The headers that were received along the response
Raw Response: Actual response received by the external API
Endpoint Response: The shape of the response received after transforming it using Response Template
To get the account ID we will skip to the end of the form, to the Endpoint Response field.
Copy the account ID.
Now, we go back to the Get Projects endpoint tab and in the JSON input editor, we assign the account ID to the basecamp_account variable as shown below.
As you enter the account ID you can send the test call. It is really important, that you use the same activity machine names in this editor as the actual activity fields machine names used in the endpoint, otherwise, it will return an error.
Once the endpoint is tested properly and all the details are in place, you can move to test action.
Testing a Paginated Endpoint
As discussed here, a paginated endpoint is used in a query activity type. So before discussing this endpoint’s testing, let's talk about some of its details first. Consider you have created your app, GitHub through our app creator.
To execute one of the queries, you have created an endpoint that fetches the list of all issues in a repository from the connected user’s account. The GitHub API documentation tells that you need to send a GET call for this, that returns an array of issues to us. The required details for the endpoint will contain the Request URI and headers, along with the pagination parameters (learn more here). As it is a GET call, there won't be any request template and you can leave the response template empty.
For the current example, we can assume that you have entered a count of 5 issues per page to be fetched from your GitHub repository. This detail from the paginated endpoint is shown below.
The rest of the parameters can be left to their default values to keep this example simple example.
After providing all the necessary details for the paginated endpoint above, you can now test it just like a regular endpoint with the Test Endpoint button at the bottom.
To send a test call to GitHub for this endpoint, you’ll need to provide the authentication type and connected account just like for any endpoint testing. As the current example is a simple one and does not have any request or response templates, you can leave the JSON input text editor empty and send the test call.
The difference in the test interface for a paginated endpoint is the inclusion of the Next Page button as seen in the bottom right of the above image. The initial test call for this endpoint will return the first page of the records fetched. For the running example, you will see the first 5 issues in the GitHub repository for the connected account. If the next page of issues is available after this test call, you will be able to use the Next Page button to receive the data for the next 5 issues. You can use this button to receive the data for as many pages as you want until there is no more data available for another page.
Test call response
For the paginated test call response, you will get a success or error message similar to any other endpoint.
Skipping to the end of the results and observing the Endpoint Response field, you will see that there are 5 objects returned in an array. This is the first page of the Issues that you requested from GitHub. The collapsed form of these 5 objects will look as shown below.
Expanding one of these objects, the details for an issue will look like this:
"Title":"test issue 1"
After viewing the above results, you can use the Next Page button to view the next page consisting of 5 more issues from your GitHub repository. The endpoint response will be similar to what is shown above with the data being replaced with those of the next 5 issues.