In this article, we're going to integrate a simple Webservice to explain how Webservices work and how the received data can then be used further. Webservices are a method to connect other environments to your own. By executing requests, you can retrieve data to process, store and show in your application. 

For this example, we use the JSONPlaceHolder API. It is specifically designed to perform requests for testing purposes. Information about the webservice other than what is discussed here can be found here: JSONPlaceHolder

At the end of this article you'll know:

  • How to define a Webservice in a Betty Blocks application.

  • How to use an action to send and retrieve data from a webservice.

  • How you can process and store the received data in your application.

  • How to show data from a webservice directly in a UI page.

The assignment we're making is divided in the chapters as listed below:

  1. How to define a webservice

  2. How to use an action to retrieve data from a web service

  3. Process and store the received data in your application

  4. Showing data from a webservice directly in a UI page

Let's go!

1. How to define a web service 

First, we have to define the JSONPlaceHolder Webservice in your Betty Blocks application. After this we can create an endpoint so we can retrieve the data. Then we store this response in a custom model.

1.1 - Go to your Back Office and hover over the Tools button in the Builder bar. An additional menu will open. Click the Webservice button to open the platform's Webservice section.

1.2 - As you (probably) haven't created a Webservice yet, this overview is empty. Click on New (top left in your screen next to the play button) to add a Webservice.

A form will appear, which we are going to fill in. Enter the following values in the corresponding fields.

  • Name: JSONPlaceHolder API

  • Protocol: HTTPS

  • Host:

  • Authentication Type: None

  • Request Content-Type: JSON

  • Response Content-Type: JSON

  • Headers: None

  • Help text: -

The Host is like a web address where we'll retrieve the information from. It's necessary to choose JSON as content types. If we don't do this, we wouldn't be able to execute an important step later on. Headers and Help text are not relevant for this assignment. It should look something like this:

Click Save  and you got yourself your first Webservice! It doesn't do much right now, so let's move on.

1.4 - To do the actual requests, we need to create a so-called Webservice endpoint. These endpoints point towards specific pages from the Webservice where in this case a set of data is served.

The right column of the Webservice we are viewing shows how many Webservice endpoints we have right now: 0. Click the + button to create an endpoint right away!
Another form appears, this time to define the endpoint.

Enter the following values in the corresponding fields:

  • Name: GET All Albums

  • Http method: GET

  • Path: /albums

  • Request Content-Type: [inherit]

  • Response Content-Type: [inherit]

The Name is basically a short description of the endpoint, describing what it is going to do. The Path is the location from which we are getting the data within the Webservice. As you can see, the Host and Path values work together to define the request URL we are collecting the data from. Leave the rest of the fields empty, as we won't be using them for now. Click Save  and you should have a form looking like this:

1.5 - These 2 components (a Webservice and a Webservice endpoint) was all we needed to do execute a request. Click Run test to see if we did everything right.

A few to things to take a look at:

  • The Request URL at the top is the full URL (Host + Path), which looks good.

  • The Response code is 200, which means everything went according to plan.

  • The Response content type says application/json; charset=utf-8 which enables us to generate a custom model (we'll get to that in a bit).

  • The Response body contains the data we received from the Webservice, which also looks pretty good!

1.6 - Time to shine some light on those Custom models: what are they and why are they awesome? This article will tell you all about it: What are Custom models? 

Click Generate custom model at the top of the form after running a test to generate a Custom model. A spinner will start as the Custom model is generating, followed by a confirmation message.

Click OK and an updated version of the endpoint will load. 

  • The Custom model we generated is connected to the endpoint and we can view it by clicking the Custom model  button on the right.

  • We can see what kind of response we receive from the endpoint: multiple (more than 1 object).

The Custom model will capture all received values in the designated attributes, which can then be easily assigned in Actions and UI webpages. It makes building a Webservice a lot quicker because you won't have to fetch every single value using text expression variables, which is more prone to mistakes made by the user.

Additional endpoints

If you thought that was a walk in the park and feel like you want another exercise, try creating some other endpoints. But this time, we'll send along some values to define what data we're going to receive and even create on the other server.

Get album by ID (Path variable)

The first additional endpoint we're going to create enables us to get a single record, based on the id of the record. 

 Create another endpoint on the JSONPlaceHolder API and enter the following values in the corresponding fields:

  • Name: GET Album by ID

  • Http method: GET

  • Path: "/albums/" + var:id

  • Request Content-Type: [inherit]

  • Response Content-Type: [inherit]

As seen in the Path option, we're including a variable. Create a Path variable called id and make sure it's correctly added to the path.

Save it, press Run test and enter 1 as Id.
This will get you a successful response, containing 1 record, with the Id 1. Great!

Get albums by userId (Query variable)

The second additional endpoint we're going to create enables us to get a set of records, based on the userId (which is an attribute within the data). 

Create another endpoint on the JSONPlaceHolder API and enter the following values in the corresponding fields:

  • Name: GET Albums by userId

  • Http method: GET

  • Path: /albums

  • Request Content-Type: [inherit]

  • Response Content-Type: [inherit]

This time, the Path option doesn't include a variable. Instead, we'll add a Query variable, which is automatically appended to the path.
Call it userId, same as the attribute in the data.

Save it, press Run test and enter 1 as userId. This will get you a successful response, containing all records containing the userId value 1. Great!

Post album (Body variables)

The third additional endpoint we're going to create enables us to send values to create a record on the other server.

Create another endpoint on the JSONPlaceHolder API and enter the following values in the corresponding fields:

  • Name: POST Album

  • Http method: POST

  • Path: /albums

  • Request Content-Type: [inherit]

  • Response Content-Type: [inherit]

We won't include variables or other dynamic values in the URL. Instead of requesting existing data, we're sending data to create something new. This is done with Body variables.
Create 2 body variables: title and userId.

Save it, press Run test and enter whatever you want in the variables. This will get you a successful response, showing you the recently created record. Great!

Note: Because of how the API is designed, it will not actually create a record and the id will always be 101. But it does react exactly how a 'real' Webservice would.

2. How to use an action to retrieve data from a web service

With the Webservice and endpoint in place, it's time to create an action so we can execute requests in a more user-friendly way, which can be applied in multiple sections of the platform. This also the first step to eventually store the retrieved data in our own data model.

2.1 - Go to the Action section of the platform by clicking on the Action button in the Builder bar. That should bring you to the following page.

2.2 - Because we don't have actions yet, this overview empty, apart from Chris' welcome message. Hi Chris!

Click New in the top left corner to add an action. The action will use the newly created Webservice, so we'll give it a similar name. Enter the following values in the corresponding fields:

  • Description: Get all albums from JSONPlaceHolder

  • Model: None

  • Background: False (unchecked)

  • Debug actions and events: True (checked)

  • Log execution of action: True (checked)

Leave Model blank, as we're not using it right now. We can also ignore the rest of the fields, as they're not relevant for this assignment. The action form should look something like:

After clicking Save, the form closes, the Visual Action Editor opens and it's time to add an event.

2.3 - Click the + between the Start  and End marker to add an event. Choose Http request as Kind and additional options appear. The JSONPlaceHolder webservice should be selected as default, because it is the only Webservice our application currently has. 

Note: If you created the additional endpoints earlier, make sure you select the correct endpoint: GET All Albums.

Basically, that's all there is for now, you don't need to adjust anything in this event. After saving, it should look like this:

As you can see, you can even navigate directly to the Webservice and the Webservice endpoint from this event. The value at Response as defines the name for the variable in which the response is stored for the rest of the action.

Additional actions

If you created the additional endpoints earlier, make sure you also create additional actions which request those endpoints. For each webservice endpoint, create an action. Make sure you create variables to pass along the required values. Assign these variables in the Http request events.

That's the first part of the action that we're building. For the second part, we need to build a model in our Data model so we store the received data in our app.

3. Process and store the received data in your application

In this assignment we will process the data from the web service response and store it in our application. A data model is required for storage. A model contains properties to store different parts of the received data. 

If you're still not entirely sure what the Data Model's purpose is, don't worry! We have a bunch of articles dedicated to them that should explain all you need to know, like this one: What is a Datamodel.

After creating a model with properties, we will further extend the action from assignment 2. Finally, we will display the stored data from the response in our standardized Back Office user interface.

3.1 - Go to the Data Model section of the platform by clicking on the Data Model button in the Builder bar. That should bring you to the following page.

3.2 - Again, click New to add a new model. We're calling this model Album as it is going to hold the album date we receive from the Webservice. The Help text isn't necessary, but feel free to enter a value.

Save the Model and click the + button next to Properties to open a new property form right away.

3.3 - The properties we're adding needs to correspond with the response of the Webservice requests. For this example, we'll add 3 properties:


  • Type: Text (single line)

  • Name: title

  • Label: Title

Typicode identifier

  • Type: Number

  • Name: typicode_identifier

  • Label: Typicode identifier


  • Type: Number

  • Name: userid

  • Label: UserId

After saving a property, it should look something like this:

With our Data Model in place, it's time to connect it to the action we created earlier. 

3.4 - Go back to the action and click Edit to open the Visual Action Editor again. It still has 1 event, now let's add a second event: a Loop event.
Because the response we receive contains multiple objects, it is served as a collection. By adding a Loop event, we can go through each object within our response.

Click the + (after the Http request event) to add an event and select Loop as Kind. Here you can select the Response as variable from the first event as collection in the Through setting. The As variable then serves each object per iteration as an object variable, call this one album. After saving, the event should look like this:

3.5 - Within each iteration of the Loop event, an event where the object is saved needs to be executed. We can do this by adding a Create event, based on the Album model we just created. Assign the title attribute from the Loop object to the title property and click Save. The event should look like: 

3.6 - With the Loop and Create event in place, the action is done for now and should look like this:

To sum it up: 

  • The Request event retrieves all the data, for example 5 album objects, which is then captured in the custom model.

  • The Loop event goes through said 5 album objects by looping through the custom model.

  • For each iteration, an object is processed in the create Album event, meaning the action executes 5 Create events.

Do not execute the action yet, though. That comes later!

3.7 - The model and property we added earlier are used for storing the received data. To view the data, we need to design our Back Office interface. Thanks to Betty Blocks, this should only take a minute or so with minimal effort.

Go to Back Office and turn on Builder Mode with E. The Back Office should still be quite empty, only show you an empty Manual. Press the + Add grid button as shown in the image below and a popup will appear.

As seen below, the settings will be pre-filled with the first model it finds. The Use options refers to a layout in which the columns are arranged. If this is the first time adding a grid for that specific model, stick to - New - and click Save .

After pressing Save , a grid is automatically generated including all available columns in alphabetical order. Stop Builder mode by clicking E on your keyboard and make sure the Backoffice looks like this:

3.8 - Fine, let's kick that action off and see if everything worked out.
Go back to the action and look for the green button saying Run. This will trigger the action manually. If everything went according to plan, you should get a Success notification.

Dismiss the notification and go back to the Back Office. The Album view we added before should contain data now!

4. Showing data from a Webservice directly in a Page

Alright! We created a Webservice, an action that uses the Webservice and added a model in which the data is saved. As the last step in this assignment, we're going to create a Page in which the data is retrieved from the Webservice on each pageload and then shown in table.

4.1 - Go to Pages and click + New page  in the top-left corner.

After the modal opens, choose UI builder. This will make it super easy to make a data table.

To get a simple but dashing look, choose Header, footer, left nav  as Layout.  

Choose Blank page as Content.

Finally, enter albums as Path value. This means the webpage will be shown when going to https://*yourapp* . The *yourapp*  part needs to be replaced with your own app url, of course.

Click Finish in the bottom-right corner and you've got yourself your first page!

The page will generate, showing you 2 main components of the UI Builder;
The Palette and the Canvas. As if we’re painting. 

The Palette holds your paint; all components provided by Betty Blocks for you to configure your pages and even components you can build yourself.

The Canvas shows you the beauty you’re creating; all components you applied to the page, showing the structure of your page.

4.2 - Before adding any component, we're going to create an action.
The thing with webpages and action is that action are always executed before the webpage is loaded. That means we can execute the Http request event like in our action earlier and use the retrieved data to load in our webpage.

Go to the page settings by clicking the third tab in the Pallete and click Open action.

This will enable an action that is executed each time the webpage is loaded. Also, the action itself will open, allowing you to add events to the action.

The next step is basically the same as what we did in the other action:

  • Click the +  to add an event

  • Choose Http request as kind

  • Make sure the correct Webservice and Webservice endpoint are selected

  • Click Save 

  • Close action

Boom. Action on webpage, done. Now we only need to include the response in our webpage. 

4.3 - Take a look at the variables on the page. Click on the second tab in the Pallete.  It should contain at least 1 variable, called item, under the section ACTION VARIABLES. This variable contains our response in a Collection (custom model).

Bells should start ringing now! If not, no worries, we got this.

4.4 - Go back the Design tab (first one) in the Pallete and search for "dynamic table".
Drag the Dynamic table component to your canvas and make sure it sticks. A blue line in the Page container should show. Release the component to see 2 columns appear in the Dynamic table component.

Open the Object Tree (fourth and last tab in the Pallette).
Double-click on Dynamic table to open its settings. Click on the Data icon and click on the blue variable button (chain-link icon) to select a variable for the Dynamic table.

Select the variable from the action as Collection for the Dynamic table.
To make this a bit more clear, enter album in the Object name setting.

By doing these last steps, we've set the received data as content for the table. Now we need to sort the data so each piece of information is shown in the correct place.

4.5 - Each object within the Dynamic table has been made available through the album variable. Therefore, we're using that variable in each Dynamic table column.

Click on the first [select a variable] to set one of the custom model's attributes as content in the fourth tab of the component. A variable browser opens with the album variable pre-selected. You just need to choose one of the attributes. Click on userId and then Select (or double click on the attribute).

The attribute is then set in that specific column. Repeat this process for the other column, but then for the attribute title

4.6 - Add an extra column to the dynamic table by clicking the dynamic table in the Object Tree and adding a child component. This is done by clicking the + button.

Same as with the other columns, select an attribute from the album variable. This time, choose the Id attribute. Your table now has 3 columns, looking like this:

4.7 - Time to try it out now! By clicking the Play button, a preview of the page is loaded. This will however still trigger the action on the page so we can see how the received data is parsed in our table. Depending on the length and complexity of a page action, a pageload can take longer.

With the received data parsed correctly, this should be the desired outcome:

Additional pages

Same as with actions, if you created the other webservice endpoints, you can also create additional pages that use them. Create input variables on the page and assign them in the action when requesting the webservice. 

Kapow! We've done some pretty cool stuff, right! And it wasn't event that hard. Let's go through the assignment and what we've done now:

  • Created a webservice ✓

  • Created a webservice endpoint ✓

  • Created an action the execute a request to the websevice ✓

  • Created a datamodel to store the received data in ✓

  • Created a webpage to execute the request on and show data without storing in our database ✓

Now that's progress! These were just the basics, the tip of the iceberg. There is so much more to learn, as each webservice is different and requires a different set up.

Did this answer your question?