Data In

Data in helps you get data from an external source, and use that data in your web app. In this panel, you can build requests, and change, sort or filter incoming data.

In this panel, we can get data "in" from an external source and use that data in our web app. We can build requests, change, filter, or sort incoming data.

In other words, the Data In panel lets you create, manage, and organize all of your apps' GET requests.

Getting started

Before we can start using data in, we have to connect to an app from which we're going to get data.

Once that's done, we can set up our first request.

In the upper right corner of the panel, click on the new request button.

This will open the request modal.

Request modal

This button will open a sub-panel where you can name your request, and choose the source of your data.

Depending on the source of data, you might be using a built-in integration or a custom REST API.

Built-in integrations

With built-in integrations, all you have to do is select the right options from the dropdowns. The content of the dropdown might vary based on the integration you're using.

On this image, you can see the options for Airtable. You can choose to which base you'd like to connect, and whether you want to get a single item (record) or a list of items.

Rest API

Getting data from a Rest API can be a little tricky for non-developers.

You can find a list of different integrations here. Note that these integration walkthroughs are managed by the community. The examples might be inaccurate or outdated.

Each Rest API can have a unique headers or query parameters which you need to send to get a response.

Yet, most Rest API's have these two things in common.

They need an endpoint, and a form of authentication. Too see which fields you need to make a request, check out the official documentation of the API.

After you specified an endpoint, you need to add relevant information to the request. You can do that in the header or in the query parameters.

Here, you can see two different examples of Rest API requests.

Headers

In this example, we're getting categories from the Zendesk API.

This request is built using key-value pairs in the header.

You can see that the key of the header is set to Authorization, and the value is set to a text field with the following string: youremail@wized.com/token:/YOUR-API-KEY.

Query parameters

Here, we're getting the current weather for a city, using the open-weather API. This request is built using key-value pairs in the query parameters. You can see that the following key-value pairs are required:

• q="city"
• appid="API KEY"
• units="metric"

You might have noticed that the name of the city needs to be a dynamic value.

In this case, the value is going to be set to the whatever is typed into our text field.

This means that the end user of our weather widget can type in any city they like.

This project is available as a free cloneable for you to inspect and play with.

Filtering, sorting and limiting data

Once you built a request, you can choose to filter, sort or limit incoming data.

Filtering

When setting up a filter, you need to set up two fields. The filter trigger and the filter condition.

The filter trigger determines when the filter is active. For example, you can to activate a filter only when a button is toggled.

The filter will be active when the value of this field evaluates to true.

The filter condition determines the filtering logic. For example, if an option A is selected, you want to show only items starting with the word A.

Sorting

The sorting modal consists of three fields. The sorting trigger, sort by field and sorting direction field.

The sorting trigger determines under which condition the sorting is active. Sorting will be active only when this condition evaluates to true.

The sort by field allows you to chose which field will be used for sorting items.

Sorting direction determines whether the items should be sorted in ascending (A-Z) or descending (Z-A) order.

Limiting

The limit modal allows you to limit the number of items that are going to be fetched. For example, you can choose to get only the first three items from a 100.

Request trigger

No matter if you're sending data out or in, each request needs to have some sort of trigger. Otherwise it will never get executed.

In this panel you can set the request trigger to execute the request:

• On page load
• After another request
• After a condition evaluates to true

Note: You can also start a request after an action happened on your site. For example if a user clicks somewhere, fills an input or if a form is submitted.

Action triggers are described in more detail on this page.

On page load

The on load trigger will execute the request as soon as the page is loaded. This is useful if you need data from a request immediately.

As soon as this request was executed, you can start using the response data. You can either render data from that request on your page or use that data in another request.

Use the on load trigger if you need the data as soon as the page finishes loading.

After another request

This allows you to sort the order of your requests. For example if you need data from a request before you can execute another request, then this feature comes in really handy.

You can select which requests need to finish executing before you can trigger the next one.

Conditional trigger

The conditional trigger will get fired as soon as the conditional statement evaluates to true.

This trigger is useful if you have a more advanced use case, which is not covered with the other requests.

For example, you might need several conditions to evaluate to true before a request can be made.

In this case, we’re checking if the user has been loaded, and if she has filled out an input. condition: (user.id && input[name])

This request will only be triggered after both conditions became true.

After request

It let's you choose what happens after the request.

You can choose any of the following options:

• Trigger another request
• Set Cookie
• Set Variable
• Navigate to another page

Overview

Gives you an overview of the request including the request trigger, request name, and the actions in which the request is used.

Responses

Here you can see all the fields which you received.

Note that if the response is an array, only the first item's values will be listed here.

These response values can be used in many ways including:

• Rendering lists on the page
• Replacing content on your site
• Creating conditional logic
• Computing values using logic

But the response values are not the only values that you can use to build your app's logic. You can also use the request state.

State

Every request has these two dimensions:

• In progress/Completed
• Successful/Unsuccessful

You can use these four states inside your application in the same way you would use any other response value.

Computed values(logic)

If a response value needs to be changed before it can be used inside of your application, you can do that with computed values.

Logic in Wized is like Formulas in Airtable or Excel.

You can take any value from the response and mutate it. You can learn more about Logic on this page.