If you have added an API to your Dropsource project and are having trouble running a request, you can use a variety of tools and techniques to troubleshoot the problem.
Check your Actions
If you have a request added to a page but it isn’t running when you test the app, make sure you’ve added a Run API Request Action to an Event that will fire when you test the app, for example an Element interaction Event, or a page lifecycle Event such as Appeared / Resume.
Remember you need to create a new build using the Test button each time you make a change to your project and want to test it again.
If you are using a cached request mode when you run your requests remember that no cached data will be available until a successful request is made to the API. You can use the network log to see when the app is making requests to the API when testing your app in the simulator.
Check your Response Binding
If your response includes an array you’re trying to display in the page, make sure you have bound the Data Source to a dynamic Elementhelp. The fields you want to display from inside the array should be bound to Elements placed inside the child of the dynamic Elementhelp (e.g. binding a response field inside a Data Source to a Text View inside a Table Cell / List Tile, which is in turn inside a Table / List).
Check any Required Data
If your request requires any Parameters, make sure they are bound with values that will be valid when the request runs (e.g. a Page Variable which will have a value when your Run API Request Action executes).
If your API requires authentication, make sure you have selected the required variables in the Set Authentication control, and that they will have valid values when the request runs (e.g. a Device Variable storing an API key value saved from the response to a previous request).
You can test the values of any required parameters or auth variables using a Set Value Action, for example to write the value of a variable into a Text View in the page, added just before your Run API Request Action.
If you’re running your app in the simulator you can access the network activity that’s logged when a request executes. Turn on network logging with the simulator open and interact with your app until the point at which it should be running a request.
Use the Preview section to drill down into the data your request is returning, including any fields you are having trouble with.
Use the Headers to establish what status code a request is returning.
Utilizing the network log:
- If your request is returning an unexpected status code, make sure you have configured your parameters correctly and authenticated the request before it runs.
- If your request does not appear to be executing at all, check out the control flow you are using with your Run API Request Action in the context of the app’s behavior before it reaches the Event you are using to run the request.
- If one request is dependent on data from a previous request, for example to pass parameters in a second request the response values from the first request, make sure the first request is receiving the required data before the second request executes, and that you’ve bound and passed the response only after it has been received from the first request. Use the Headers section to verify the parameter values being sent to a request.
- Remember that API data will only appear in the network log in cases where a request is actually fetching data from your backend and not if the app is using cached data stored locally.
If you can see the responses from your API request showing up in the network log but not displaying inside your app, your response structure may not match what’s in your API spec. In this case Dropsource will not be able to bind the data to your UI – check that your responses match the spec using an external tool such as Stoplight.
Test with Request Events
If you have bound response fields to your page Elements but can’t see any values appearing when the request runs, try a test using the request status code Events. Open the request in the API tab and select Events. Your request may return more than one status code, so respond to the Event you’re trying to troubleshoot (typically it will be 200 for a successful response). Use a Set Value Action to display some arbitrary text in the page, for example the word “returned” in a Text View.
Test the app again and check to see if the text appears. If your text is not displayed, the app is not receiving a response from the request, so you will need to troubleshoot the request outside Dropsource, for example using Stoplight or Postman (or cURL if you’re comfortable using a command line interface).
If the text appears, you know the app is receiving a response, so next you can drill down to the data values, e.g. by altering the Set Value Action to display a field from the response via the Event Data – this can be a value such as the length of an array.
If the response is received but your field isn’t displayed, the body of the response is possibly not what you expected it to be. As with no response being received, you will need to troubleshoot the request response detail outside Dropsource, for example using one of the tools below.
Whether you used Stoplight to author your Swagger / OpenAPI specification or not, it makes an effective testing environment for your API requests. If you didn’t use Stoplight to author your spec, you can import it in there for testing. By running test requests in Stoplight, you can troubleshoot any issues with parameters, auth data, and response structures.
To test a request in Stoplight, navigate to the relevant endpoint and click Send Request.
Enter values for any required parameters in the Path, Query, and Body sections. Include your auth details either in the Headers (e.g. API Key access token), Body (e.g. login details specified in JSON for OAuth2 Password), or Auth (e.g. Basic authentication).
You will see the response returned including any error messages for unsuccessful requests.
If your test requests run successfully in Stoplight but not in Dropsource, there may be an issue with where your API is hosted, or the detail of how the data is returned.
Test Using Postman
Postman is a utility we generally recommend when working with an API you plan to connect to a Dropsource app. If your requests aren’t running successfully in Dropsource, try them out in Postman using the same details for auth and parameters, and verify not only that the response is returned, but that the structure matches what you have defined in your Swagger / OpenAPI spec.
To test a request in Postman, open a new tab, select the method ( GET, POST, PUT, PATCH, DELETE, etc), enter the endpoint URL, and fill out any authentication and parameter detail required.
Include form data and raw JSON body parameter values in the Body section:
You can specify both path and query parameters using the Params control – enter a name and value for each.
Path parameters can also be added to the URL using the syntax: :parameter-name (but make sure you provide a value for them when testing).
If your API requests need to be authenticated, enter the details using the Authorization control (e.g. for Basic auth), or in the Headers section – like this example, which is testing a request with an API Key value, so the header is named Authorization and the value is preceded by Bearer (Dropsource builds this structure automatically when your request uses a key for authentication):
When your request detail is complete, hit Send and check out the response. If the response comes back as you expect in Postman but not in Dropsource, get in touch and our developers will take a look.
Copying the JSON response from a test request in Postman into Stoplight as an example response is a quick way to generate the structure returned from an endpoint when authoring your Swagger / OpenAPI specification.
See the Postman documentation for more detail on defining your requests.
Ask for Help!
If all else fails, you can access help via the Help button in the editor.