You write and edit the custom app configuration with the VS Code extension as you would edit a JSON file on your PC. The custom app configuration is downloaded to your PC when you open it from VS Code and uploaded to Make when you save it. The custom app configuration is stored on your PC as temporary files. The temporary files are deleted after you close the configuration.

The custom app configuration is associated with your account in Make. The communication with the VS Code extension and your Make account is authorized with an API key. To set up the VS Code extension you must provide an API key with the appropriate API key scopes. Generate a new Make API key if you don't have one:

Develop apps in Make UI

The Make UI allows you to browse in Example and Custom apps you previously created.

When developing an app, you can work with elements such as base, connections, webhooks, modules, RPCs, and custom IML functions.

Discover how to develop apps using the available features in Make UI.:

Develop apps in VS Code extension

The VS Code extension supports all jobs available in the Make UI, additionally, it empowers developers with the following capabilities:

• Importing & exporting the apps

• Cloning components within the app

• Support for apps' local development, enabling:

  • pulling updates or new app elements to the local workspace and a repository

  • collaborative development

  • control over code contributions

Learn how to get the most out of the VS Code extension:

The Apps platform documentation is divided into topic groups. The topic groups are structured the same way as you would navigate inside the Apps builder in Make.

App structure

Section APP STRUCTURE describes how to define and configure the basic elements of a custom app. The basic custom app elements are listed in the top menu in the custom app configuration, for example: Base, Communication, Modules .

App blocks

Every structure element is divided into blocks. Some of these blocks appear in multiple places and share the same purpose, others do not.

App components

COMPONENTS are like bricks for APP BLOCKS. Block doesn't exist without components. Multiple components form a block.

Pick a brick that suits your needs and use it. You can use multiple separated components or combine them together by using the nestedproperty. Play around and find the best components combination for you!

[
    {
        "name": "email",
        "label": "Email",
        "type": "email"
    },
    {
        "name": "name",
        "label": "Name",
        "type": "text"
    }
]

[
    {
        "name": "select",
        "label": "Select",
        "type": "select",
        "options": [
            {
                "label": "Case X",
                "value": "caseX",
                "nested": [
                    {
                        "name": "email",
                        "label": "Email",
                        "type": "email"
                    }
                ]
            },
            {
                "label": "Case Y",
                "value": "caseY",
                "nested": [
                    {
                        "name": "name",
                        "label": "Name",
                        "type": "text"
                    }
                ]
            }
        ]
    }
]

When you create your app in the Make platform, you are using the web code editor. The web code editor has a bunch of handy features to make your app development easier:

1. Hints with links to the apps platform documentation with more details.

2. Code reformat button with a label showing the data format. The available editor box data formats are:

   • jsonc

   • json

   • javascript

   • markdown

3. Context aware code suggestions for the jsonc data format. The web code editor gives you hints what parameters or properties you can add to the custom app code. The code suggestions work even for RPCs.

4. Hints displayed when hovering over the custom app configuration.

5. Custom app code validation for the jsonc data format. If you misspell a code property name, or if you place a property in an invalid code section, the web code editor highlights the error.

6. One button to save changes in all editor boxes on the page.

1. Controls to expand and collapse the code. To view the controls, hover over the space between your code and editor line numbers.

1. The editor highlights the IML syntax so it's distinct from the rest of the code.

Web code editor keybindings

The web code editor is built on the same backend as the Visual Studio Code. If you know your way around Visual Studio Code, you will find that some keybindings also work in the web code editor. Some of the most useful web code editor keybindings are:

For Windows users:

• Ctrl + Shift + H: shows a cheat sheet with selected shortcuts

• Ctrl + S: save your changes to all of the editor boxes on the page

• Ctrl + F: search in the editor box content

• Ctrl + H: search and replace in the editor box content

• Ctrl + Space: show a list of code suggestions valid in the current cursor context

• Shift + Alt + F: format code

• Ctrl + /: toggle line comments

• F1: display web code editor command and keybindings reference

For MacOS users:

• Ctrl + Shift + H: shows a cheat sheet with selected shortcuts

• Cmd + S: save your changes to all of the editor boxes on the page

• Cmd + F: search in the editor box content

• Opt + Cmd + F: search and replace in the editor box content

• Ctrl + Space: show a list of code suggestions valid in the current cursor context

• Shift + Opt + F: format code

• F1: display web code editor command and keybindings reference

Set or change the icon

To view, set, or change the icon of the app, click the right mouse button on the app name and choose the Edit icon option.

A new view will appear and you will see the preview of the current app's icon inside the app module.

You can change the icon by clicking the Change icon button. The file upload dialog will appear and after you confirm the chosen icon, it will be uploaded back to Make. The change icon view will close and the new icon will appear in the left tree.

2. Click the Make icon on the VS code sidebar. Clicking on the Make icon activates the Make Apps Editor. You get notified in a pop-up window that you haven't yet set up a development environment.

1. Click the Add environment button to launch the environment setup or execute the command: >Make Apps: Add SDK Environment from the command palette.

1. Fill in the API URL in the next pop-up window. The API URL depends on your Make zone. For example, the US1 Make zone has the API URL: us1.make.com/api.

1. Fill in the label for the environment in the next pop-up window. Press Enter to confirm the environment label.

The Make Apps Editor extension restarts with the environment configuration.

A new sidebar appears in VS code with a list of your custom apps and Make open-source apps. If you previously created any, your custom apps are listed in the block My apps. The Make open-source apps are listed in the Open source apps field at the bottom of the VS code sidebar.

Switching among environments

In Make Apps Editor, you can work across multiple environments.

Easily identify the active environment by checking the indicator in the bottom status bar.

Upon clicking the environment indicator, you can switch among multiple environments.

You can add another environment by issuing the >Add SDK environment again (follow the steps starting from the 5th).

Useful settings

You can add extra settings in Extensions > Make Apps Editor > Extension Settings > settings.json file.

Here are some settings for better performance and experience:

• Set editor.formatOnSave to true in VS Code settings. Source codes will be formatted automatically when you save them.

• Set editor.quickSuggetions.strings to true in VS Code settings. Keyword recommendations will automatically show up while you're typing in IML strings too.

Log out and log in to an environment

You can log out using the >Logout command and log back in by the >Login command.

When you log out, the API key is removed from the settings.json file. To log in again, you will need to enter your API key.

Make Custom Apps documentation is a guide for developers looking to create their own apps for themselves or others to use on the Make platform. This documentation will walk you through how to use Make Apps Editor in Make UI and in Visual Studio Code to create and manage those custom apps, as well as best practices and common approaches for development.

Introduction to creating custom apps

When there is a service that you want to use in Make but the service is not yet available in Make, use the apps builder to create a custom app. The only requirement is that the service has to have an API.

In the apps builder, you write down a JSON configuration. This configuration is then used by the Make platform to generate all connections and app modules for you. If you are working on a complicated custom app, you can write a custom IML function with JavaScript.

There are two options directly supported by Make to write the custom app configuration:

• The web interface of your Make account instance.

• The Visual Studio Code (VS Code) extension.

The benefits of using VS Code over the Make account web interface are for example:

• first-class support for JSON format, like syntax highlighting and completion,

• automatic checking of the JSON configuration validity, notably in terms of parameter type checking and correct object context,

• predefined project structure for every custom app you create,

If you want to write the custom app configuration in the Make web interface, navigate to Custom apps in the left sidebar menu of your Make account. You might have to click on the three dots at the bottom of the left sidebar to view the Custom apps option.

Important notes

• All modules can be tested directly in scenarios.

• Changes to communication configs are immediately active.

• You can see raw requests/responses in your browser's console.

• Changes in parameters and interface requires you to reload scenario editor page.

• We use JSONC (JSON with comments) in all sections except common data.

Collaborative development

Edit the source code

To start editing the source code, find the item you want to edit in the left menu and click it. A new editor will appear and the current source will be downloaded from Make. You can edit it as a normal file. If your app contains some RPCs or IML functions, they will be provided to you.

After pressing the shortcut CTRL+S, the source code will be automatically uploaded back to Make.

Add a new item

To add a new item, such as a module, connection, webhook, etc., right-click the corresponding folder and click the New <item> option.

Each time the prompt will appear, you will be asked to fill in information about the newly created item. Just go through it. Your new items will always appear under the corresponding folder.

Edit metadata

To edit metadata (for example to change a label of a module), right-click the desired item and select the Edit metadata option from the menu.

The prompt will appear allowing you to change allowed values. If you don't want to change a value, skip the field by pressing the Enter key.

Change the connection or webhook

To change the attached connection or webhook of an item, right-click the item and select the Change connection (or webhook) option from the menu.

The prompt will appear allowing you to change the connection or webhook. If possible, there will also be an option to unassign the current connection without assigning a new one.

Also, the prompt to assign an alternative (secondary) connection will appear. Please note, that the alternative connection should not be the same as the main connection. You can leave it empty.

Delete an item

To delete an item, right-click it and choose the Delete option.

You will be asked to confirm the deletion. If you answer Yes, the item will be deleted from the app.

Generate the interface code

Utilize the Interface Generator to generate an interface. Familiarize yourself with the Generator's functionality by following the steps described in the Interface Generator article below.

2. Click on the API tab.

3. Click the Add token button.

4. Set API scopes for the API key.

The required scopes for the Make Apps Editor are:

• sdk-apps:read

• sdk-apps:write

5. Click the Save button to confirm selected permissions.

6. Copy your new API key to your clipboard and store it in a safe place. This is the only time when you can see the whole API key. The API key is required to set up the VS code extension.

You have created a new Make API key. All your Make API keys are listed in your Make profile in the API tab. In the API tab, you can view permissions for all your keys and delete unused Make API keys.

Unlike online development within Make Apps Editor or web code editor, local development doesn't provide access to advanced features such as prefilled code templates, IML object suggestions, and seamless integration with Scenario Builder for continuous testing.

Instead, it offers a self-contained environment for app creation and modification, ideal for situations where internet connectivity is unreliable or where comprehensive testing within Scenario Builder isn't required. Additionally, local development allows synchronization with Git repositories and provides full search capabilities across the entire codebase.

Develop a new or edit a current component in a local app

1. If you don't have an app cloned yet, do so by following this manual:

1. The structure of the app is very similar to the one in Make Apps Editor. Each group of components, such as RPCs, modules, or custom IML functions, contains the component directories with corresponding code files.

1. If you need to edit the current code, click the file you want to edit and develop your changes in the opened tab. Save the changes.

2. If you need to create a new component, right-click the corresponding components' folder and select New Local Component: <component's name> (beta), for example, New Local Component: Module (beta).

1. Follow the dialog and enter the component's name, label, and other corresponding parameters as you are used to from Make Apps Editor.

1. Once all the questions are answered in the dialog, a new component with the corresponding files is created.

1. Write the code in the corresponding files and save the changes.

Commit the changes in the Git repository

Deploy the changes from the local app to the Make app

The changes in components or new components can be partially deployed to Make, or the app as a whole can be deployed to Make.

The changes in components or new components can be partially deployed to Make, or the app as a whole can be deployed to Make.

1. Follow the instruction, that fits your case, below.

1. In the dialog, select the origin where the changes should be deployed.

1. The changes or new components are now available in the Make app. The new app version can be thoroughly tested in Scenario Builder. If you utilize testing and production apps, you can deploy the changes or new components to the production, after the testing app passes the testing phase.

To start the development of an app in a local directory or git repository, or start tracking changes in your app, you need to clone the Make app to the local workspace.

Open the local folder

First, you need to open the folder where you intend to store the app, in Visual Studio Code.

Clone the app to the local folder

Once the repository in Visual Studio is set, you can proceed to cloning the app to the local folder.

1. In the opened window of Visual Studio Code, go to Make Apps Editor and right-click the app you wish to save to your repository. Select Clone to Local Folder (beta).

1. Read the text in the dialog window and confirm reading by clicking Continue.

1. Enter the workspace subdirectory name, where the app should be cloned to. If the subdirectory doesn't exist yet, it will be created. The default subdirectory is set to src. Click Enter.

• Exclude (more secure) - Select, if your app contains sensitive data, such as Client ID and Secret. Common data will not be stored in your local workspace or a repository.

• Include (for advanced users only) - Select, if you want to store the common data in your local workspace or a repository. Be aware that storing common data outside of Make could potentially expose the app to vulnerabilities.

1. The app is now cloned to the local folder.

Start versioning the local app

To properly start the versioning of your app in the git repository, follow the steps below:

1. Go to the GitHub Desktop app and open the repository where you deployed the current version of your app. You will see a list of new files.

2. Enter the Summary of the commit and click Commit to main.

3. Now, the first version of your app is logged. Every new change or a new component in the app will be considered a new change.

1. Optionally, click Publish branch.

Whenever you create a new package of changes, you can commit them to create a new version in the Git repository.

1. Go to the GitHub Desktop app and open the repository with the latest version of your app. You should see a list of new changes.

2. Enter the Summary, optionally the Description of the commit, and click Commit to main.

1. Now, the new version of your app is logged.

One feature available to developers is the "Compare with Make" functionality. This tool allows developers to compare the code in their local app with the code in their Make app.

By leveraging this feature, developers can easily identify differences, track changes, and ensure consistency between their local and Make apps.

To compare the code of a local component with a remote component, right-click the local component block and select Compare with Make (beta).

Once clicking, a view with the local code on the right side, and the remote code on the left side will appear.

Once you finish the development of new changes and components in the Make app you can push the changes to the local app. To do so, follow the steps below.

1. Go to Visual Studio Code and open the local directory with the local app file.

1. Locate the makecomapp.json file and right-click it. In the pop-up menu select Pull All Components from Make (beta) option.

1. In the dialog, select the testing app origin.

1. All changes in the existing components will be pulled into the local components. If there is a new component, a dialog will appear. Either confirm the creation of the component by pressing Enter or click Ignore permanently/do not map with the remote option.

This tutorial will guide you through the steps to create a custom app with a module. You will use the Make "Virtual Library Demo API."

If you want to test the Virtual Library Demo API click the link:

A new tab opens in your web browser with the API response in JSON format:

{"result":"Hello, World!"}

The development of a custom app in Make is divided into several steps. These steps are described in detail in the following subpages.

In the app development process, there are situations where it can be highly beneficial to push changes to multiple app origins. This is especially useful when managing different versions of an app, such as maintaining both a testing and a production app.

In this manual, the steps to create a new app origin for a testing app version are described.

2. If you haven't created a testing app in Make, do so by creating a new app in Make and naming it <App Label> Testing so it is obvious it is the Testing version.

3. Go to the makecomapp.json file in the local app repository. Locate the origins array of the collection and enter a new item by copying the code below and editing the values as instructed under the code.

"origins": [
    { /* --- Existing origin --- */ },
    {
        "label": "Testing",
        "baseUrl": "https://eu1.make.com/api",
        "appId": "my-first-app-test",
        "appVersion": 1,
        "apikeyFile": "../.secrets/apikey"
    }
]

• label - the label of the local origin

• baseUrl - the URL to the origin's zone

• appId - the name of the app

1. Save the changes in the makecomapp.json file.

When you want to create a custom app, you have to set up the custom app metadata, such as:

• a unique name of the custom app

• custom app label that Make displays in the scenario editor

• color of the app's modules

• app icon

This page will guide you through these settings.

1. Navigate to Custom apps in the left sidebar menu in your Make account. You might have to click on the three dots at the bottom of the left sidebar to view the Custom apps option.
2. You will see a list of sample custom apps. Click Create a new app in the top right corner.

3. In the Create an app pop-up, fill in:

• Name: The unique identifier of your custom app. Make uses the custom app name internally. Note the requirements under the text box.

• Label: The custom app label. Make will display the custom app label in the scenario editor. You can use any characters in the custom app label.

• Description: Description of your custom app. This field is optional.

• Language: The language of your custom app and its descriptions.

• Audience: This parameter has no effect currently. The custom app is accessible regardless of the user's country.

• App icon: Upload icon. The icon upload is optional. Make will use this icon to create your custom app logo. The icon has to:

  • be a file in .png format

  • have 512 x 512 px dimensions

  • have a maximum of 512 kB size

Make processes the icon file so that:

• All color pixels in the icon file are converted to white

• All transparent pixels in the icon file are converted to your theme color

1. Click Save changes to confirm the custom app settings.

You created a custom app in Make. The next pages will guide you through setting up the app's base, connection, error handling, and modules.

These common settings are:

• Base URL

• Authorization

• Error Handling

• Sanitization

Set up base for the demo API

In this step, we will set up the Base for our custom app. The custom app uses the Virtual Library Demo API.

1. Navigate to your custom app settings.

2. Click on the BASE tab.

3. The first code block already contains a JSON snippet:

{
    "baseUrl": "https://www.example.com",
    "log": {
        "sanitize": ["request.headers.authorization"]
    }
}

1. Replace the URL address https://www.example.com with the Virtual Library Demo API base URL: http://demo-api.integrokit.com/api/v1

2. Press Ctrl+S to save changes.

The base settings of your custom app look like this:

{
    "baseUrl": "http://demo-api.integrokit.com/api/v1",
    "log": {
        "sanitize": ["request.headers.authorization"]
    }
}

Write a test

It's possible to write tests for your custom IML functions. You can use it function and asserts as you may already know them from Mocha and other testing frameworks. Our example function has the following code:

So, let's write a test for this function. We'll create two blocks.

As you can see, the it function accepts exactly two parameters, the name of the test and the code to run. In this code, we can verify expected outputs using assert.ok() function.

Run a test

To run a test on a specific function, right-click the function name in the tree and select the Run IML test option.

The test will start and you'll see the output in the IML tests output channel.

1. When you have successfully logged in and have the environment set, it's time to develop your first app. To start, click the + icon in the header of My apps section or call the >New app command directly from the command palette.

1. First, you will be asked to fill in a label. That's the app's name the users will see in the Scenario builder.

1. Next, the app ID will be generated for you. It will be used in URL paths. However, it should be clear to which app it leads. It has to match (^[a-z][0-9a-z-]+[0-9a-z]$) regular expression.

1. Then, you'll be asked to enter the app's version. Currently, the version 1 is only supported.

1. Next, you'll be prompted to enter the description of your app.

1. Then, enter a color theme for your app. This is the color the app's modules will be seen as in scenarios. The theme is in hexadecimal format. For example, the Make app's color is #6e21cc.

1. The next prompt will ask for the app language. That is the language of the interface of the app. Most of the apps in Make are currently in English.

1. The last prompt is for countries where the app will be available. If you don't pick any country, the app will be considered global.

And that is it. After you confirm the last dialog, your brand-new app will appear in the My Apps view and you can start coding.

This page describes how to develop an application with the Make Apps Editor, managing production and test versions of the application.

• The developer writes and tests the code with the test application in Make.

• The developer tracks changes in the local git repository, pulling changes from the test application.

• The developer pushes the changes to the production application from the local testing app when they finish the development and testing.

This process improves the maintenance and stability of the application because the development does not influence the production version of the application. In addition, all changes can be tracked in a git repository, providing a clear and organized development workflow.

Prerequisites

To start the development of testing and production app versions, the following is needed:

• The production version of an app in Make - If you already have an app that is already in use, use it as the production app.

• The testing version of an app in Make - Create a new app in Make, with no content, that will function as the testing version of the app.

• Optional, version control with Git - To properly track all changes in the local app, it is recommended to use a Git repository, for example, GitHub.

Development flow

Below is a diagram explaining how a developer can develop testing and production app versions.

Create a testing version of an app

First, you will need to create a testing version of Make app. Follow the instructions in the article below, to create a new origin to the Make testing app.

Once the origin for the testing app is successfully created, you will need to deploy the current code from the app, that already exists, which we can call "Production".

1. Right-click on the makecomapp.json file and select Deploy to Make (beta).

1. In the dialog, select the app origin that represents the testing app.

1. The content of the local app will now be deployed to Make. Whenever a new component is about to be created, a dialog will prompt for confirmation. Press Enter to confirm the creation of the component. If you don't want to create the component, click Ignore permanently/do not map with remote option.

1. The app has been deployed to Make.

Develop the components in the testing app

Now, you can start developing new components or editing the current components in the Testing app in Make, and thoroughly test the app in Scenario Builder.

Pull changes from the testing app to the local app

Once you finish the development of new changes and components in the testing app you can push the changes to the local app.

Deploy the changes from the local app to the production app

To synchronize changes made to the testing app with the production app, follow the steps outlined in the manual below.

Prerequisites

To start the collaborative development, ensure that you have set up the testing and production app versions by following this article.

Roles

• Owner of the production app - Every app in Make can be owned by a single Make account. The owner of the production app manages the deployment of the new local app version to the Make app.

• Developers of testing apps - Each developer manages their own testing app in Make, which is connected to the local app from the Git repository.

Collaborative development flow

Below is a diagram explaining how developers can collaborate on app development.

Modules are the key component of your app. They are basically wrappers around specific app/service functionality, which is exposed via an API endpoint.

There are three basic types of modules: Action, Search, and Trigger (polling).

Setting up a new module for our demo API

Creation of a new module

To create a new Module, click on the tab MODULES. The list of all modules your app consists of, will be shown (empty for now). Click the large button with the plus sign and choose Create a new Module.

A dialog will pop up, where you can name your module, choose its type, and provide some description. Fill the dialog as shown and click Save.

Make sure the tab Communication is active and replace the content of the text area with the following JSON and save the changes (Ctrl+S):

{
    "url": "/helloworld"
}

The url key specifies the API endpoint path. The URL will be joined with baseUrl specified earlier to produce the full URL of the API endpoint: http://demo-api.integrokit.com/api/v1/helloworld.

[]

Congratulations! You have just created your first module.

Testing the new module

Now, we will test our new module. Open a new browser tab, login to Make, in the left main menu choose Scenarios and create a new scenario. Click the yet undefined “questionnaire” module to bring up a list of all the apps. Search for your new app by typing its name in the Search field: Custom App. Click your app and a list of all its modules will be shown, currently just the newly created Hello World module. Click the module to select it. An empty module settings panel will pop up saying “There are no configurable options for this module.”.

Close the panel and run the scenario. Click the bubbles above the module to pop up the panel with information about processed bundles. In case you have successfully followed this tutorial, you should see the following output of your new module.

Perfect! You just learned how to create a new module and make it work. But we can make it better! We can make it more user friendly. Continue reading below.

Setting up interface of the module

Since we now know the structure of the output, we can specify the Interface. So we can set up our scenario right away, with no need to first execute the module to learn the output's structure.

Below, you can see an example of a list of available parameters to map from Shopify > Watch Orders module. Notice that the Shopify module wasn't executed yet (the bubble is not displayed).

In the panel with the output, click on the button circled below and choose Download output bundles option.

Then, a new panel will appear, with the original response from the endpoint. Copy the text to your clipboard.

Go back to the tab with your app and make sure you are in the settings of the Hello World module. Select tab INTERFACE. You can see a JSON snippet:

[
    {
        "name": "id",
        "type": "uinteger",
        "label": "User ID"
    }
]

In the right upper corner, click on Options button and choose Generator.

A new panel will appear. There, paste the previously copied JSON from your clipboard and click Generate.

A new data structure will be generated. Copy it to your clipboard and close the panel.

In the INTERFACE, replace the JSON structure with the new structure.

[
    {
        "name": "id",
        "type": "uinteger",
        "label": "User ID"
    }
]

[
  {
    "name": "result",
    "type": "text",
    "label": "Result"
  }
]

Perfect! You just learned, how to work with interface and automatically prepare a list of expected parameters from the module's output. Now, let's make it harder!

Adding mappable parameters

In Make modules, you can define, what data should be passed to the API. So we can create a new record or define, what should be returned.

The Demo API endpoint /helloworld takes two parameters greeting and name. Click the following link to open the API response in your browser:

The API should return the following JSON response:

{"result":"Hi, Johny!"}

So let’s make our Hello World module configurable by adding the parameter greeting. Switch back to the Mappable parameters tab, replace the empty square brackets with the following JSON and save the changes(Ctrl+S):

[
    {
        "name": "greeting",
        "type": "text",
        "label": "Greeting"
    }
]

Switch to your scenario and refresh the browser window (F5). Click the Module to pop up its settings panel. The panel now contains one text field labeled Greeting. Fill Hi:

Press OK and run the scenario. Though, if you click the bubbles above the module to pop up the panel with information about processed bundles, the module’s output will be identical as in the previous run.

This is how the log from the run looks like, focus on the Request Headers tab:

Notice, that there is no parameter called greetings sent.

It is because we need to specify the structure of the request in the module. Specifically, we have to pass the content of the greeting parameter to the API.

Switch back to the MAPPABLE PARAMETERS tab and click the COMMUNICATION tab. To pass the parameter greetings to the API, you have two options:

You can either add the parameter to the url key:

{
    "url": "/helloworld?greeting={{parameters.greeting}}"
}

Or you can add a new key qs (query string) and add the parameter there:

{
    "url": "/helloworld",
    "qs" : {
        "greeting": "{{parameters.greeting}}"
    }
}

Save the changes (Ctrl+S), switch to your scenario, and run the scenario. Click the bubbles above the module to pop up the panel with information about processed bundles, where you should see the modified module’s output:

Also, you can check how clear the run in DevTool looks. Finally, the parameter greeting is passed in QS (query string):

You can now practice your skills and try to add a parameter name to your Hello World module.

Congratulations! You have just learned how to pass data from a module to an API. Also, you have learned how you can debug possible issues using our Make DevTool. If you are ready to learn about setting up connection in your app, continue below.

APIs usually employ some sort of authentication/authorization to limit access to their endpoints.

Make platform provides you with a list of the most used types of connections while in every each there is a code prefilled. You only need to edit it up to your and/or API's needs.

Mostly, you will need to change the URLs and names of the parameters.

Setting up a connection for our demo API

While the /helloworld endpoint was accessible without any authentication/authorization, the other endpoints of the Demo API will require an API key.

Let’s try to call endpoint /books that should respond with a list of books in the library:

Without providing the API key, the response will contain the following error:

Copy

{"error":"Invalid or missing API key"}

To enable the user of your Module to specify her/his own API key (assuming each user has got her/his own API key to access the API), you need to create a Connection.

We have covered the basics of creating a simple module. Since the /books endpoint will always return an array with items, you will need to create a new module type Search. Now, let’s see how to update our search module with a variable API token for each user.

Click the tab Connections. The (probably still empty) list of all your connections will be shown. Click the large button with the plus sign and choose Create a new Connection. A dialog will pop up, where you can name your connection and choose its type. Fill the dialog as shown and click Save.

The new Connection will appear in the list. Click the new Connection. A page with two tabs will be shown: COMMUNICATION and PARAMETERS.

A pre-configured communication will look like this:

{
    "url": "https://www.example.com/api/whoami",
    "headers": {
        "x-api-key": "{{parameters.apiKey}}"
    },
    "log": {
        "sanitize": ["request.headers.x-api-key"]
    }
}

...
"response": {
    "metadata": {
            "type": "email",
            "value": "{{body.data.user.email}}"
        }
},
...

Since our Demo API doesn't have any suitable endpoint, we will not use any.

The code should be as below:

{
    "headers": {
    "api-token": "{{parameters.apiKey}}"
        },
    "log": {
        "sanitize": ["request.headers.api-token"]
    }
}

[
    {
        "name": "apiKey",
        "type": "password",
        "label": "API Key",
        "required": true,
        "editable": true
    }
]

Once you finish the connection configuration, you can go back to your search module and click Attach Connection.

An Attach Connection dialog will appear. There, select the currently created connection.

When we are setting up a connection, we should not forget about the base!

Therefore, click BASE tab and edit the code:

{
    "baseUrl": "http://demo-api.integrokit.com/api/v1",
    "headers": {
        "api-token": "{{connection.apiKey}}"
    },
    "log": {
    "sanitize": ["request.headers.api-token"]
    }
}

Awesome! You just learned how to add a new connection, attach it to an existing module, and map the connection data in base. Now, it is the right time to learn, how to make error handling, continue below.

DevTool consists of 3 main modules - Live Stream, Scenario Debugger, and Tools. Each of them is described in detail in the next subpages.

Debug IML in Web Browser

Debug IML in VS Code

There're options to debug your IML code locally on your computer.

1. Automated testing with Mocha

The first option is to do automated testing with Mocha. The process and examples can be found in the link below.

2. Debug code in Visual Studio Code

1. Copy your IML code.

2. Go to VSC -> File -> New Text File (Shortcut: ⌘ + N - on MacOS, Ctrl + N - Windows/Linux).

3. Paste your IML function. To execute a code you will need 3 more things:

   2. Call function. Since we are testing the function locally, we cannot run a scenario to execute it. To imitate scenario execution we need to call a function by its name and send the input, that we specified before, inside it. Example: myFunction(input) .

   3. Remove all IML functions called inside. All debug() and iml.function() should be removed or replaced by similar JavaScript functions.

4. Put breakpoints on your code (it's red dots on the left side of line numbers).

5. Upper menu Run -> Start Debugging -> set Node.js as debug environment

6. Enjoy! On the left side of VSC, you will see variables that are being processed at the moment. Go through the code step by step and find your bug

function removeType(input) {
	debug(input)
	delete input.type; //removes type
	input['year'] = iml.parseNumber(input.year); //parses number from text
	return input;
}

function removeType(input) {

    //Initially JavaScript doesn't support debug(),
    //so don't forget to replace it with console.log()
    
    console.log(input); //instead of: debug(input);

    delete input.type;

    console.log(input);

    // JS doesn't support in-build Make functions.
    // If you are used in-build IML functions,
    // don't forget to replace them with JS functions,
    // otherwise you will get an error.

    input['year'] = parseInt(input.year);
    /* instead of: input['year'] = iml.parseNumber(input.year); */

    console.log(input);

    return input;
}

const input = {
    type: 'car',
    make: 'Honda',
    model: 'Civic',
    year: '2022'
};


removeType(input);

Live Stream displays what is happening in the background once you've hit the Run once button in your scenario. It allows you to view the following information for each module in your scenario:

• Request Headers (API endpoint URL, HTTP method, time and date the request has been called at, request headers, and query string)

• Request Body

• Response Headers

• Response Body

After you run a scenario, click one of the tabs in the right panel of Integromat DevTool to view the desired information.

Searching Requests and Responses

Enter the search term into the search field in the left panel of Integromat DevTool to only display requests that contain the search term.

Removing requests from the list

To clear the list of requests recorded by Integromat DevTool, click the trash bin icon in the top-right corner of DevTool's left panel.

Enabling console logging

Retrieving the request in the raw JSON format or cURL

cURL can be retrieved using the Copy cURL button next to the Copy RAW button.

If API supports pagination, it should be implemented. In order to make sure the pagination works as intended, it is recommended to set the page size to a low number, if possible, see the example below:

{
    "url": "/contacts/filters/{{parameters.filter_id}}",
    "method": "GET",
    "qs": {
        //"per_page": 100
	"per_page": 10 //set value for testing
    },
    "response": {
        "output": "{{item.contact}}",
        "iterate": "{{body.data.contacts}}",
        "limit": "{{parameters.limit}}"
    },
    "pagination": {
        "qs": {
            "page": "{{pagination.page}}"
        },
        "condition": "{{body.data.max_page > body.data.page}}"
    }
}

Then, it is needed to create as many records as one page and a few more. You can do it by using Flow Control > Repeater module, which also returns the ID of the repeat. Map this ID in the following module as it will help to differentiate the records.

Once the testing records are created, you can test your search module. Thanks to using the ID from the repeater, you are able to see whether the records are ordered and how, and whether the records are correctly retrieved, e. g. they are not being duplicated (1 page retrieved multiple times).

In the console, you can also effectively control every retrieved page and its size.

Possible pagination issues:

• The stop condition limit set by the user doesn't work. Therefore all the records that exist in the account are retrieved (or only the first page if there is also the issue from the point below).

• The next page condition isn't set correctly so the next page isn't retrieved even though it should according to the user's limit and the content of the account.

• The next page condition isn't set correctly so the next pages are retrieved even though all records were already retrieved. They can either be duplicated or without any records (without looking into the console, you will not spot them).

• The pagination is not optimized so even though there is a parameter saying “there is no other page to retrieve”, it still retrieves the next page which is empty (developer implements the pagination for offset even though he/she could implement it using the cursor parameter).

• The value in the parameter page is too low therefore there are too many pages being retrieved (= too many calls).

• Not common - the records are duplicated because the pages are overlapped (1st page 1-100, 2nd page 100-199 instead of 1-100, 101-200).

During the development of your app, you will probably experience multiple issues with your app and/or API. Therefore, you will need to use Make DevTool and/or console in order to debug your app. Continue below in order to learn how!

Basics of debugging

You can easily debug your app using Make DevTool or Chrome DevTool's console. Learn how to use Make DevTool or Chrome DevTool's console below.

Debugging of pagination in list/search module

When the GET endpoint, which you are using, supports pagination, you need to make sure the module uses it correctly. Learn how you can test if your pagination works correctly below.

Debugging RPC

Make apps platform has a tool for testing the behavior of your RPCs. Thanks to this tool, testing of RPCs is easy. Learn, how to test your RPCs below.

Debugging of custom IML functions

Implementing a custom IML function might get complicated, therefore, you will need to learn, how to effectively debug your custom IML functions. Learn how below.

Since any API endpoint can return an error during an execution of a scenario, Make brought a way, how to handle such errors. Therefore, all apps in Make, custom included, should have error handling implemented. This way, the modules are more transparent as users of them exactly know, what caused the error. Also, error handling in a scenario can be used.

Setting up an error handling for our demo API

When you were trying your new search module, you were probably experiencing error 401, but you didn't know why was that, if you didn't check Integromat DevTool. Since Make offers advanced error handling, you should set your app the way, so you could understand what is wrong with your module/scenario right away and use error handlers.

Enter your search module into your scenario and create a new connection with a random API key, if you haven't done so before. You should see the error:

In DevTool, you should see this output:

We need to make sure the error from the body of the response is returned in the module's output as well.

As you learned before, error handling should take part in base, since it is an element, which is shared among all modules and remote procedures. Therefore, open base and replace the current code with the code below:

{
	"baseUrl": "http://demo-api.integrokit.com/api/v1",
	"headers": {
		"api-token": "{{connection.apiKey}}"
		},
	"response": {
		 "error": {
            	     "message": "[{{statusCode}}] {{body.error}}"
        }},
	"log": {
		"sanitize": ["request.headers.api-token"]
	}
}

Now, go to your scenario again, and execute the search module. You should now see the detailed wording of the error:

Voila! You just learned all the basics of custom app development in Make!

If you want to continue in development of your custom apps, you can explore our docs and learn more!

Click on an app in the Apps list. You will get a page with nine tabs. In this guide, we will focus on the custom app's main components:

Now you know the main components of a Make app. Your next step is to set up the custom app Base.

1. Output a message to the web console

You can use debug inside your IML functions to print a message or mid-results of your code. During the function execution debug messages will be visible inside the console of your browser.

2. Debug JavaScript snippet in Chrome DevTool

1. Open Developer Tools in Google Chrome.

2. Go to Sources -> Snippets. Create a new snippet.

3. Paste your code. Before execution you will need 3 more things:

   2. Call function. Since we are testing the function locally, we cannot run a scenario to execute it. To imitate scenario execution we need to call a function by its name and send the input, that we specified before, inside it. Example: myFunction(input) .

   3. Remove all IML functions called inside. All debug() and iml.function() should be removed or replaced by similar JavaScript functions.

4. Press ⌘ + Enter (on macOS), or Ctrl + Enter (on Windows/Linux).

5. Click on a line number to put a breakpoint and start debugging! In Scope, you will see variables that you are using at a particular moment. In Console, you will see all your console.log() messages.

function removeType(input) {
	debug(input)
	delete input.type; //removes type
	input['year'] = iml.parseNumber(input.year); //parses number from text
	return input;
}

Location of debug tool in RPC

The RPC debug tool can be found by following:

1. Go to Custom apps tab.

2. Select your custom app from the list.

3. Go to the Remore Procedures tab inside the custom app.

4. Select an RPC you want to debug.

5. Click Test RPC.

Navigation inside RPC

Compare the tabs below to understand how things work inside RPC on Make.

By default after creating a new RPC, you have a template of the communication code, which should be modified based on your needs.

Also, there is Parameters tab, which by default is empty. Here you can add any parameter needed. In the same way, you can also do it in the Mappable parameters from a module.

RPC debug tool

RPC debug tool works the same way modules do.

1. Specify the connection and other fields (i.e. parameters) if needed.

2. Click the Test button.

3. The call, which you specified before in the RPC communication, will be executed.

The Tools section features useful tools that can help you build your scenario. Detailed descriptions for each tool are available in the Make documentation.

The Base section should contain data that is common to all (or most) requests. At the very least, this should include the root URL, the authorization headers, the error-handling section, and the sanitization.

Base URL

Make sure that the Base URL uses the URL of the API, which is shared among all modules or their majority.

When the service has a different domain for each user, the domain should be asked for in the connection and then the value should be used in the Base tab.

{
    "baseUrl": "https://api.mailerlite.com/api/v2"
}

{
    "baseUrl": "https://{{connection.domain}}.freshsales.io"
}

{
    "baseUrl": "https://mydomain.freshsales.io"
}

{
    "baseUrl": "https://mailerlite.heroku.com/development"
}

Authorization and sanitization

The Base section should also have authorization, which is common for all modules. This authorization should use the API Key, Access Token, or Username and Password entered in the connection. The sanitization should hide all these sensitive parameters.

Examples of possible authorization and sanitization:

{
...
    "headers": {
        "Authorization": "Token {{connection.apiKey}}"
    },
    "log": {
        "sanitize": [
            "request.headers.authorization"
        ]
    }
...
}

{
...
    "qs": {
        "access_token": "{{connection.accessToken}}"
    },
    "log": {
        "sanitize": [
            "request.qs.access_token"
        ]
    }
...
}

{
...
    "headers": {
        "authorization": "Basic {{base64(connection.username + ':' + connection.password)}}"
    },
    "log": {
        "sanitize": [
            "request.headers.authorization"
        ]
    }
...    
}

{
...
    "body": "There is something {{parameters.secret}} hidden here.",
    "type": "raw",
    "log": {
        "sanitize": [
            "request.body<parameters.secret>"
        ]
    }
...
}

Error handling

Each service sends an error message when an error occurs. This most of the time happens when the request has wrong parameters or values or when the service has an outage. That's why error handling is required.

The error handling code should correspond to the structure of the server response. Let's assume that the JSON response has the following format in the cases where something goes wrong:

{
    "error": {
        "code": "E101",
        "message": "The company with the given ID does not exist."
    }
}

Here's how the error section should (and should not) look:

"response": {
    "error": {
        "message": "[{{statusCode}}] {{body.error.message}} (error code: {{body.error.code}})"
    }
}

"response": {
    "error": {
        "message": "{{body.error.text}}"
    }
}

Module types

Universal module

Each app should have a universal module. This module is there to allow users to use not supported API endpoints using their connection created to the app.

Make sure this module has:

• correct label and description,

• correct url which starts with the base URL,

• correct connection.

Using the base URL

All of the modules should build on top of baseURL from the Base section (simply by starting with a forward slash /). It is very unlikely that a single module will need to have a completely different URL than the rest.

Module names

Module labels

Every module should have a label that precisely describes the module's use. For each type of module, there is a standard naming convention. But it may change depending on the functionality of the module. The label should be composed of the verb expressing the intended action (Create, Update, Watch, etc.) and the name of the entity being processed (Customer, Invoice, Table, etc.).

Triggers and instant triggers (webhooks)

These modules watch for new data in a given service and return it. Compose the label according to this pattern Watch <watched node>

Examples:

• Watch Events

• Watch Photos

• Watch Deleted Files

Actions

These modules write data into a service, modify data in the service, or retrieve a single result. Compose the label using simple verbs like Create, Get, Update and Delete and the modified or created node. Use the naming convention of the service you are implementing.

Examples:

• Create a Note

• Update a File

• Get a User

• Delete a Task

Searches

These modules retrieve data from the service and allow retrieving one or more results. Compose the label using simple verbs like Search or List. Use the naming convention of the service you are implementing.

Examples:

• Search Files

• List Tasks

Module descriptions

In a few words, describe the functionality of the module. Write the description in the third person and capitalize only the first letter of the first word in the description (like a normal sentence structure).

Example: Description for the module Update a Time Entry:

Triggers use the "Triggers when..." in the descriptions. For example, the description for the module Watch New Users should be: **"**Triggers when a new user is created."

Names and labels of input and output parameters

For labels, try to use the same names and conventions as in the integrated service. It helps users to use the app in Make and not be confused.

For variable names, use the same names that come from the service API. It helps when debugging for both advanced Make users and support agents. Ideally, the output of the module should be the same as the response from the API.

Example:

[
    {
        "name": "id",
        "label": "ID",
        "type": "text"
    },
    {
        "name": "note",
        "label": "Note",
        "type": "text"
    },
    {
        "name": "firstName",
        "label": "First Name",
        "type": "text"
    },
    {
        "name": "shortUrl",
        "label": "Short URL",
        "type": "url"
    }
]

{
    "id": "59b1396a4a22a7a3bfc78e22",
    "note": "Hey",
    "firstName": "John",
    "shortUrl": "https://trello.com/c/LdcrM4wa"
}

Abbreviations

Be sure to use the correct uppercase for abbreviated words, such as ID, IDs, URL, GPS, VAT, etc.

While in Live Stream, you can't display historical logs in a scenario, in Scenario Debugger you can.

It displays the history of the scenario runs and enables you to search modules by their name or ID.

Searching modules by their name or description

To search the module by its name, enter the search term (name or module's ID) in the search field in the left panel of Integromat DevTool in the Scenario Debugger section.

Open settings of a module

Double-click the module's name to open its settings in the scenario editor.

View request or response details

View request details by clicking the desired operation.

Every connection should have a way how to check if the used API Key/Token is valid (Validation Endpoint). That means each connection should have a part that uses the used API Key/Token against some endpoint that requires only the API Key/Token to run. For example, User Info endpoint or any endpoint which is used to List data.

The validation endpoint is located:

• OAuth1 and OAuth2 - the info directive

• API Key, Basic Auth, Digest Auth, Other - the url which is in the Communication tab

Connection metadata

It is recommended to use the metadata parameter to store the account's name or email. This allows users to easily distinguish their stored connections, especially if they don't name their connections in a good manner.

...
"response": {
    "metadata": {
            "type": "email", //allowed values are "email" and "text"
            "value": "{{body.data.user.email}}"
        }
},
...

Editable connection

To allow users to edit a connection:

1. Go to the Parameters tab of the connection.

2. Check that each parameter which original value should be kept secret has the password type.

   The parameters with the password type don't show the original connection's parameter value, while the parameters with the text type show the value used by the current connection.

3. Add the editable: true property for each parameter in the connection.

For example:

[
    {
        "help": "Your MailerLite API Key.",
        "name": "apiKey",
        "type": "password",
        "label": "API Key",
        "editable":true,
        "required": true
    }
]

Error handling

Error handling can be used from the Base tab and follows the same rules.

The only difference is where to use it in what type of connection. For example, in connection types OAuth 1.0 and OAuth 2.0, the error handling should be in the "info" part.

For the next example, suppose that when you call /users on your service, you will get a list of users in body.data.

This example will correctly output each user that was returned:

{
    "url": "/users",
    },
    "response": {
        "output": "{{item}}",
        "iterate": "{{body.data}}",
        "limit": "{{parameters.limit}}"
    }
}

Iteration and pagination

Pagination parameters

The pagination section should only contain parameters directly influencing the actual pagination. These will be merged with the rest of the parameters defined in the qs section, so there is no need to define them all again.

Limiting output

The modules type Search and Trigger(polling) should return everything including by pagination. However, these modules should also allow users to limit their output, that is, how many bundles they return.

Search module limit example:

{
    "url": "/clients",
    "method": "GET",
    "qs": {
        "per_page": 100
    },
    "response": {
        "limit": "{{parameters.limit}}",
        "output": "{{item}}",
        "iterate": "{{body.clients}}"
    },
    "pagination": {
        "qs": {
            "page": "{{pagination.page}}"
        },
        "condition": "{{body.next_page}}"
    }
}

[
    {
        "name": "limit",
        "label": "Limit",
        "type": "uinteger",
        "help": "Number of clients to return",
        "default": 10
    }
]

Support for query and filtering options

Certain APIs provide support for custom queries or filters when searching records, such as invoices. In Make, our goal is to offer query and filter capabilities to both regular and advanced users.

Therefore, we have implemented two methods of achieving this functionality, and ideally, users should be able to choose between the two options.

A predefined query

We have utilized the familiar filter setup format found in Scenario Builder. With this approach, users are not required to learn the query format. Instead, they can simply set up the query in a manner similar to configuring filters.

When the module is executed, a custom IML function constructs the query, adhering to the specified format.

A custom query

Users have the option to manually compose their own queries. This feature is particularly valuable when the API supports new operators that are not yet available within the module.

To assist users in leveraging the query field effectively, the following helpful information should be provided:

• Query format: The guidelines for structuring the query.

• Example of a functional query: An illustrative sample query as reference.

• API documentation URL: Direct access to the API documentation with query specification.

The Static Parameters tab is deprecated and should be left empty. All fields should be inside the Mappable parameters.

Responsiveness approaches

Bear in mind that there are two approaches to responsiveness in a service.

• Synchronous - The service upon an action request returns a result, which can then be processed in the following modules in a scenario.

• Asynchronous - The service doesn't return anything at all, or doesn't return useful output, e. g. a processed file.

Comparison of synchronous and asynchronous approaches

Handling of asynchronous approach

When a web service doesn't support a synchronous approach and the common use case of the module requires support, it should be added on the app's side. Basically, there should be two (or more calls) executed instead of only one:

• create a job call - a call that requests for the job, e. g. conversion of a file, file upload,

• periodically check the status of the job - execute repeated calls to obtain the job's status**,**

• ask for the result of the job - once the status call returns the awaited status, request the result, e. g. result file.

Example

After importing a JSON file to a web service, it requires a certain period of time to process the file. In this case, we have to keep checking if the status of the entity changed from processing to completed. In this case, when the status is completed, the result is already part of the response.

Epoch in polling trigger

The trigger module has an Epoch section that defines what "Choose where to start" looks like. This section is an RPC that uses everything in COMMUNICATION including the pagination. This means there can be an issue if the user has too many objects which could be returned by this RPC so that is why a "limit" parameter should be specified here.

‌ The "limit" parameter should be a static number which should be at max 300 or 3 * number of objects per page.

API endpoint requires from and/or to date parameters

Some API services require date parameters that define the interval of records to be retrieved, e.g. from and to, fromDate and toDate, etc.

In this case, it is important to handle the date parameters correctly.

Mapping all parameters

Using an IML function or omitting a parameter

Sometimes, you don't want to map all parameters in the body for some reason:

• the parameter shouldn't be sent at all (technical parameters such as selects, etc.)

• the parameter should be sent somewhere else than in the body, e.g. in the url

• the parameter has to be wrapped in an IML or custom IML function

Handling arrays, nulls, and empty strings

Make and other third-party services transport values in many different formats. It is important to know how to handle the value types of arrays, nulls, and empty strings.

Bad practices

Let users decide what parameters they want to send to the service. Make has a feature to show how to process values. This feature allows users to define exactly how Make should behave when the value is "empty". For example, if a user defines that they want to send a specific field to a service even if the value is null , empty string, or an empty array, it will be sent to the service. In module communication, config passes parameters without any modification.

Date parameters

When a field is a type "date", it should be possible to use our keyword "now" as a value, which means, the field should accept ISO-8601 date format and if the service requires only the date (no time) or a different format like timestamp, this formatting should happen inside the module.

Query String (QS)

The query string parameters should be defined using the qs object in order not to be embedded directly in the URL. Embedded parameters are those parameters that are after a question mark.

This will enforce the correct encoding of both static and dynamic parameters.

If you need to specify a query string parameter, you can do:

But a better way is to use a special qs collection.

The headers, qs, and body collections represent request headers, query string parameters, and body payload. The key is the variable/header name and the value is the variable/header value. You don’t need to escape values inside those collections.

The above request can be rewritten as:

The example above will not work. But if you want dot notation for some reason, you can use it directly in the parameter name:

This will create a query string that looks like this: ?someProp.anotherOne.and-one-more=THIS%20WILL%20WORK

Order of the mappable Parameters

The mappable parameters should follow this priority order:

1. required parameters

2. optional parameters

3. advanced parameters

When defining the input parameters, try to use the same order as in the integrated service. Place required parameters at the top if it is possible. Position parameters in logical groups.

Helps under parameters

Using a help directive, you may specify a hint of what is expected for the parameter when it is not that obvious from the label or the expected value is more complicated. The text should start with a capital letter and end with a period. Supports Markdown, such as _italic_, **bold**, `monospace`, , or URL [example](http://example.com).

Example:

Advanced parameters

Services like CRMs use large amounts of input parameters. In these cases, you can mark less important parameters as advanced. When the parameter is marked as advanced, then by default it isn't shown in the GUI. It can be found in the advanced parameters instead after the user clicks on Show advanced settings.

Example:

If the app has over 10 modules, the modules should be put into special groups. These groups should be named after the entity with which the modules work, or after the type of the job, the modules are executing.

Also, the modules inside these groups should follow this order:

1. Trigger module

2. Create module

3. Update module

4. Get module

5. Download/Upload Module

6. List/Search module

7. Delete module

Use cases of RPCs

Use RPCs for every field that accepts parameters like IDs and other stuff that is hard to guess or get for users.

Also, RPCs come in handy in a case, when a user only needs to understand the functionality of the module, mostly the list of available parameters in the interface. In this case, the aim is not to offer a complete list of all items, but a sample of the last 100 or so items the user could select from when testing the module or setting up the scenario for the first time, before replacing it with mapped data used in automation.

Mode edit

When adding an RPC to a Get, Update, or Delete module, it is required to add:

to the code so when a user first opens the module, they will be able to immediately map the value. However, if needed, they can also switch to getting the value from an RPC.

When it comes to Search/List modules, it depends on the hierarchy level of the entity. If the entity is up in the hierarchy, e.g. a “customer” or a “deal”, and there are not many RPCs in the input, they should not have the mode set to “edit”. However, if the entity is low in the hierarchy, e.g. "E-mail attachment", it should have the mode set to “edit” since the user will probably not want to list attachments of a single e-mail repeatedly.

Finally, a Create module should not have the mode set to "edit", unless it contains a very large number of RPCs in its input. This is because pre-loading a large number of RPCs would significantly increase the waiting time for the user.

Pagination and limits

Just like modules, RPCs can use pagination to show more records than just the ones on the first page. However, limits should be also set on how many objects the RPC shows so it doesn't load forever.

The limit should be between 300-500 if the API returns 100 or more objects per page. If the API returns less than 100 per page, then the limit should be 3 times the amount of objects per page.

For example, if API returns 25 records per page, the limit should be 75. You can also set a condition for the pagination to stop further requests when no more data is needed.

Custom Apps Development Training

Training with 37 lessons and 4.5 hours of video content where you can learn all the aspects of custom apps development on Make.

If you are new to custom apps on Make or want to freshen up your knowledge about apps developing on Make, enroll in the training!

Make's community - Custom Apps

Custom Apps category in community is dedicated to all Makers, especially to those who develop custom apps. If you need help, ask the community! You can participate there as well!

Stack Overflow

100+ questions regarding the custom apps development in Integromat/Make.

You can check if someone already asked the same question and got a response. If not, feel free to post a new question there!

Make's channel full of useful videos:

150+ useful videos about Scenario Builder in Make and many more.

Make's documentation

Documentation about Scenario Builder, apps, and many more.

Regular expressions 101

Recommended tool for experimenting with regular expressions. Just make sure to tick the ECMAScript (JavaScript) FLAVOR in the left panel.

Regular expressions generator

Regular expressions generator for those, who struggle with regex.

Free editor for images

A free editor that you can use to edit your file with a logo to be used in an app.

Make helpdesk

Contact us in case you need help or you didn't find any information you need.

Deprecated: Open source apps

Make will introduce a different way of sharing open-source apps.

Therefore, the Examples tab has been removed and is not available anymore.

Update approaches

Bear in mind that there are two approaches to updating entries in a service.

• Partial Update - The service updates only specified parameters sent in the API request and other empty parameters will be unchanged. This is the most common approach for APIs.

• Full Update - The service requires all parameters to be updated in an update request. If some parameters are omitted, then they will be cleared or overridden to default values in the service. This is extremely user-unfriendly and should be avoided.

Handling of full update approach

If the API doesn't support a partial update approach, it is needed to add the support on the app's side. Basically, there should be two calls executed instead of only one:

• GET call - a call that retrieves the current record and saves it in temp,

• UPDATE call - an update request which contains the user's input merged with the missing parameters from temp.

Example using OR directive

If there are a few parameters available, you can use simple OR (||) directive, which ensures that if there is no value in the particular parameter available, the value from temp is mapped instead.

Communication

Example 2 - IML function

If there are a lot of parameters available, it is worth writing an IML function, which merges the parameters with the output from temp.

Communication

IML Function

Example 3 - considerating read-only parameters

There might be read-only parameters, which can't be updated, e. g. CreatedAt and UpdatedAt parameters. In this case, it is needed to ensure these parameters will be omitted.

IML Function