1. Home
  2. Documentation
  3. Integrating with Dropsource
  4. API Tools
  5. Troubleshoot your API Requests

Troubleshoot your API Requests

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.

run place search
A Google place search API request added to the Tapped Event of a button.

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.

ⓘ Note

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).

data source binding
The place search comment text field displayed in a Text View inside a dynamic Table / Cell in the example app.

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).

photo save key

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.

Use Network Logging

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.

Network Log Data

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.

Network Log Headers

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.
ⓘ Note

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.

show trace text

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.

trace field

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.

Test Using Stoplight

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.

stoplight 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).

stoplight request headers

You will see the response returned including any error messages for unsuccessful requests.

stoplight test

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:

postman photo save login
Postman testing the login endpoint for the Photo Saver app Bubble API.

You can specify both path and query parameters using the Params control – enter a name and value for each.

postman query

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).

github postman
Postman testing using path parameters for the GitHub example app API.

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):

postman auth bearer
Postman testing the Photo Saver API picture retrieval endpoint with an API Key value returned from the login request.

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.

ⓘ Note

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.

help button

Was this article helpful to you? Yes No

How can we help?