Make supports writing custom apps in Visual Studio Code (VS Code) with the Make Apps Editor extension. You can get the VS Code extension from the VS Code Marketplace or install it in the Extensions tab in VS Code.

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!

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,

Follow the instructions to configure the VS Code extension.

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.

If you are developing a custom app for the first time, check out the section first.

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

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. Hovering over built-in IML functions shows their docs.

1. Hovering over custom IML functions provides a link to the function definition.

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

For a full reference of the web code editor keybindings check the official VSCode documentation and the official VSCode keybindings cards:

• MacOS

• Windows

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.

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.

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

1. Navigate to in Make.

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.

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:

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

Debug IML in Web Browser

Debug IML in VS Code

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

During maintenance of your app, you might need to apply changes or create a new app's version.

The process is different between / apps and apps.

Changes and versioning in custom apps

All changes take immediate effect in running scenarios. You should take this into account while changing your code!

Changes and versioning in approved apps

Since your app has been approved, every change made to the app is visible only to you unless we commit it. You can safely add and test new functions and when they are stable, you must to check and release them for users.

Approval of changes in Make

Once you decide that the changes, you have made so far, should be applied to the public version of your app as well, you will need to pass update review.

In order to do so, open the Review tab in your app, and update the form. Enter links to your updated scenarios with new logs, where we can see the functionality of updated modules, and/or links to new scenarios with logs, where we can see the functionality of your new modules. Then, submit the form by clicking Update review.

Our Senior Developers will check your changes. The changes can be either approved or rejected.

In case of approval, you will be informed by e-mail, that your changes have been approved.

While in case of refusal, our senior developer will contact you with further details and/or recommendations for the correct solutions.

What is considered a change that has to be approved by Make

• changes in current connection, modules, RPCs, custom IML functions, webhooks

• a new connection, modules, RPCs, custom IML functions, webhooks

• new theme and/or logo of the app

Rollback of changes in Make

If you need to have all changes, that you have made so far, rollbacked, contact us via .

Sanitization will help you to protect sensitive data (passwords, secret keys, etc.) from leakage.

Consider this to be the base:

In a module, you need to add a custom header programmatically.

That results in the base being overwritten by the result from the IML function. To merge both collections, use this special IML syntax inside the module:

This section explains the work with updates in private or public apps.

Changes

In custom apps, which haven't been approved by Make, it is not possible to keep track of changes as there is no Diff tool available.

If you need to keep track of your changes and you are not planning to have your app approved by Make, you can export the current version of your app every time you make a change, using VS Code extension, and store the files on GitHub or any similar tool.

Versioning

If you find out, that there has been a new API version implemented, or there have been major changes in the current API made, you should create a new app.

This way, you will make sure that everything is consistent and that there are no breaking changes made in the current app.

The Base section is used for setting up the authorization. The most of services require the authorization key to be sent either in headers or in the qs (query-string). If you set the authorization in the Base all modules and RPCs will inherit it.

Examples

The most common ways of authorizing are:

API key in headers

{
    "headers": {
        "x-api-key": "{{connection.apiKey}}"
    }
}

API key in query string

{
    "qs": {
        "apikey": "{{connection.apiKey}}"
    }
}

OAuth 2 access token in headers

{
    "headers": {
        "authorization": "Bearer {{connection.accessToken}}"
    }
}

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.

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.

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.

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.

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.

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.

If you are uncertain how to do so, simply follow the steps in the corresponding section in the article.

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.

1. To properly track the new version of your local app in a local workspace or git repository, follow the corresponding steps in this article.

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.

1. If you haven't cloned the production app to a local workspace, do so by following the manual.

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.

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:

• Base

• Connections

• Modules

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

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.

Make DevTool allows you to debug your Make scenarios by adding an extra pane to the Chrome Developer Tools. Using this new debugger pane, you can check all the manual runs of your scenario, review all the performed operations and see the details of every API call performed. Additionally, using Make DevTools you can see which module, operation, even which single response causes an error in your scenario. This helps you debug your scenario, and get your scenario back on track.

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

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

To enable logging into the console, click the computer icon () in the top-right corner of the DevTool's left panel. Logging into the console is enabled when the color of the computer icon switches to green.

Retrieving the request in the raw JSON format or cURL

To retrieve the raw JSON content of the request, click the Copy RAW icon () in the top-right corner of the DevTool's right panel.

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

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.

Module types

Modules should be associated with the correct type, depending on their functionality. Detailed descriptions of different types of modules can be found in our Modules docs as well as in the Best Practices guide.

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.

More about this module can be found here.

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.

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

The universal module should be left inside "Other" group. More about groups can be found here.

When you create a custom app you can use it anytime. When you finish the development and testing of your app, you might share the app with selected users with an invite link. But if you want to provide your custom app to all Make users, we at Make want to make sure that your app is up to Make apps standard. To check that, Make has the app review process.

App review prerequisites

If you want to provide your app to other Make users, you have to request a review of your app first. Check the App review prerequisites for rules and requirements for the App's code.

When you request an app review, the Make QA team will check your custom app's code. If your app meets Make's requirements and follows the app development best practices, Make will publish your app and make the app available to all Make users. Otherwise, the Make QA team will contact you with instructions how you should improve your custom app.

Request app review

After you check the app review prerequisites, you can request an app review. Click the link below for instructions on how to request an app review.

Check the review status

The review process consists of multiple stages. You can check the current stage of the review in the Flow tab.

Approved app

When Make approves your app, the app becomes available to all Make users. Because of that, your custom app management changes. Read the linked section to find out more.

Maintenance of approved app

It is important to keep your app up-to-date and provide support to your app's users. More information can be found below.

Every app on Make has its own logo and color. The combination of logo and color represents the app. With a distinct logo and color, the users quickly see which module belongs to which app.

App theme

The app theme is the module color in hexadecimal format. For example, the Make module's color is #6e21cc.

App logo

To add a logo to your custom app, you need to make sure that your file with the logo meets these requirements:

• an image file in .png format

• square dimensions: minimum size 512 x 512 px and maximum size 2048 x 2048 px

• a maximum size of 512 kB

Make processes the logo file so that:

• Areas in the logo that are white or transparent will be displayed as the color specified in the Theme field.

• Areas in the logo that are black will be converted to full opacity and will be displayed as white.

• Areas in the logo that are in color or are semi-transparent will be displayed as the color between white and the color specified in the Theme field.

Examples of how logos are rendered

Work with semi-transparent pixels

An app can have only one theme color. You can use multiple transparency levels to give your logo multiple shades of the theme color. You can create a 3D effect too.

Updating the app's theme and/or logo

You can update the custom app's logo anytime. Navigate to your custom app settings and click Options > Edit.

Logo changes not visible?

You can check the stage of your custom app review in the App flow tab. The App flow tab contains a list of app review statuses and their description. When you click the App flow tab, your browser automatically scrolls and highlights the current review status of your app.

If you have published your app or requested a review for a new app or an app update, you have available the Review tab. You can check the Review Status section at the bottom of the Review tab to see all activity that happened during the review.

Every entry contains 4 columns:

• Date and Time - When the activity happened.

• Action - Name of the activity.

• Status - Available only with action "Review status updated.". The status of the app's review.

• Comment (manual) - A comment with additional information or context.

Possible actions are:

When Make approves your app, your app becomes available to all Make users in their scenarios. To the users, an app developed Make looks the same as the app developed by you. You have to take your custom app's management responsibly, since any Make user might be using your custom app in their scenario.

After a custom app's publishing, Make provides you with a development version of your custom app. You can find the development version of your app by searching for your app in the scenario editor:

The search now has two results:

• The app with the tag custom app: This is a development version of your app that only you can see and work with. When you update your custom app, the development version of your app will have your changes.

• The app without a tag: This is a public version of your app. Anyone can use this version of the app. Changes to this version have to be approved by Make.

Tracking code changes in VS Code extension

Once there is a change saved in an approved app, the app is marked with * next to the name. Also, every module with its blocks, where the changes are available, is marked with the *.

To view what's changed right click the item and pick the Show changes option.

A compare view will appear and you'll see the changes that have been made.

Tracking code changes in web interface

Once there is a change saved in an approved app, a new tab Changes will appear. There is a list of all changes available in the particular app.

After clicking on a diff log, a page with the particular app block will open, with a dialog informing your about available changes. For a detail diff file, click Show diff button.

A compare view will appear and you'll see the changes that have been made.

There's no dedicated JWT connection type because the JWT itself is only a "special format" of the Authorization header. Everything works the same way as described in Basic Connection chapter.

Generating a JWT

To generate the token, you can use the following example.

{
  "url": "https://mock.api/connect",
  "temp": {
    "jwt": {
      "iss": "https://iam.the.issu.er",
      "iat": "{{timestamp}}",
      "exp": "{{timestamp + 30000}}",
      "scope": ["rest_webservices"],
      "aud": "https://iam.the.audien.ce/services/rest/auth/oauth2/v1/token"
      },
    "options": {
      "header": {
        "kid": "{{parameters.clientId}}"
	}
      }
    },
    "headers": {
      "authorization": "Bearer {{jwt(temp.jwt, parameters.clientSecret, 'HS512', temp.options)}}"
    }
}

As you can see in the example, first, we build a JWT payload inside the temp variable called jwt, but you can use any other name for that variable.

Then, inside the Authorization header, we call the IML function named jwt. The jwt function accepts four parameters:

1. The payload to be signed.

2. The secret to signing the payload.

3. The algorithm. The supported algorithms are HS256, HS384, HS512, and RS256. The default value is HS256. This parameter is optional.

4. A custom header to customize the JWT authorization header. This parameter is optional.

This function will output a JWT token which you can use in the Authorization header.

Types of dedicated webhooks

Attached dedicated webhook

The new URL address, which has been created, is automatically registered to the service using attach procedure, and can be unregistered using detach procedure.

Not attached dedicated webhook

The new URL address, which has been created, has to be then registered manually by the user. Basically, user copies the URL address and pastes it to the webhook's settings of the web service.

Use if the API endpoint returns a single response.

Module Actions

Components

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.

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.

• Cloned production version to the local workspace - Clone the app to the local workspace, if you haven't done so yet, by following this .

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

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.

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.

• Theme: The color that Make uses for your custom app modules and forms. Use the .

• 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

For detailed guidelines on how to create the app logo check the .

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.

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:

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

The best way to deal with errors is to use an error handler. An error handler connects to a module with the error handling route. When the module outputs an error, the error handling route activates and runs the error handler.

When all errors are handled, Make keeps scheduling scenario runs instead of disabling the scenario.

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:

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!

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.

How to process the API response

The best approach is to return the API response as it is. In many cases, the response varies based on the user who is using the app, as responses can contain different custom fields, etc. If the response returned is unchanged, and if still all the parameters aren't described in the output parameters, Make will automatically learn additional parameters from actual incoming data and propose them for mapping.

Response output

A module's response output should be defined for the case when a request is fulfilled successfully. The output definition should under no conditions contain error messages (this belongs in the Base section's error handling) nor the additional metadata which may arrive bundled with the actual response information.

Showing dates correctly

There are multiple ways how a date can be returned from the service, either as a timestamp or in any format the service finds fit. It is important to parse this date to our ISO 8601 format so it is shown in an output of the module as a date using the users' localization and timezone.

Make is using ISO 8601 format: YYYY-MM-DDTHH:mm:ss.sssZ

Any other format, even just without milliseconds won't be shown correctly in the output and needs to be parsed using an IML function.

Interface

The interface describes the structure of output bundles and specifies the parameters which are seen in the next modules. It should contain the full response from the API, including nested parameters.

You can generate an interface using our Interface Generator, learn how in section.

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.

This section explains the work with updates in an app.

Changes

Once an app is approved by Make, the code is locked and it starts to be versioned. When a new change is made in the code of the app, it automatically creates Diff files, which contain detailed information about the changes. Every change made to the app is visible only to you unless we commit it. You can safely add and test new functions and when they are stable, you must follow our guidelines to have the changes checked and released to users. The Diff files are available in both environments, the web interface, and . Also, you should always make sure the existing scenarios.

Versioning

It is recommended to create a new version of the app, when there are major changes in the current API and/or there is a new API version available, and it is not possible to update the current app without breaking changes.

This way, you will make sure that everything is consistent, there are no breaking changes made in the current app, and at the same time, users will be able to upgrade the modules in their scenarios using our upgrade module tool. Read more about the upgrade module tool in our Make Help Docs:

Creation of a new version of an App

If you need to create a new version of your app, create a new app, and develop its content. Once your app is finished, request for . During the app's review, do not forget to mention the app should be compiled as a new version of the current app.

The new URL address, which has been created, is automatically registered to the service using procedure, and can be unregistered using procedure.

Attach

The Attach remote procedure is used to automatically attach a webhook to a remote service. Please note that you will need to detach this RPC later, and for that you will need this remote procedure’s Id.

To save the remote webhook id (in order for detach to work), you must use the response.data collection. This collection will be available in the detach webhook remote procedure as webhook IML variable for you to use.

The webhook collection with webhook’s data is also accessible in regular remote procedure calls if the call is processed in the context of an Instant Trigger. For example, if you create a dynamic interface for an Instant Trigger based on parameters entered when the webhook was created.

Detach

The Detach remote procedure is used to automatically detach (delete) a webhook from a remote service when it is no longer needed. The only thing you have to do is to correctly specify the url to detach a webhook. No response processing is needed.

Implementation of a shared webhook

Shared webhook should be registered by the developer of the app. All notifications from the service for all users will be sent to Make by calling this URL, which is generated when creating the shared webhook. On the Make's end, the corresponding user account will be matched.

Matching the user's account with an incoming event

Since the webhook is shared among multiple users, it is needed to match the incoming events with their owners and deliver them correctly. In order to do it, it is needed to work with uid parameter. Uid parameter can be obtained in connection.

Example

There are six basic types of modules:

Universal Module can be used to perform an arbitrary API call to the service's API. It allows the user to specify all parameters of the request while using the App's connection.

Every app using API should have a Universal module. Each app can have one universal module at most.

There are two types of universal module available. Choose one depending on the API you use:

Components

Components of the Universal Module are the same as for the .

Available IML Variables

You can use all of the IML variables available in in the universal module, except for the iterate directive.

Universal in a Scenario

When a universal module is used in a scenario, it is recommended to use it together with JSON > Create JSON module. Not only it is much easier to create the structure of JSON for the universal, but also all characters, which are part of JSON definition and should be considered as letters, are escaped.

Communication

Parameters

Limits

As we can't wait for the RPC's output to infinity, there are limits.

Best Practices

Since we can't wait forever for the RPC's response, when the parameters of the module are loading, there are some best practices you should know.

1. Install the Make Apps Editor. You can get the Make Apps Editor from the VS Code Marketplace or install it in the Extensions tab in VS code.

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.

1. Copy your Make API key in the last pop-up window. If you don't have an API key, follow the procedure to create a Make API key.

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.

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:

   1. Input example. You can either type it manually or use debug() inside the IML function on Make and copy input from the developer console of your browser (more about debug() here).

   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.

6. If you're interested to explore Chrome DevTools check their docs here.

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

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.

[
    {
        "name": "firstName"
        "type": "text",
        "label": "First Name"
    },
    {
        "name": "lastName"
        "type": "text",
        "label": "Last Name"
    },
    {
        "name": "email"
        "type": "email",
        "label": "Email"
    },
    {
        "name": "taskId"
        "type": "number",
        "label": "Task ID"
    }
]

[
    {
        "name": "firstName"
        "type": "text"
    },
    {
        "name": "taskId"
        "type": "number"
    },
    {
        "name": "lastName"
        "type": "text"
    },
    {
        "name": "email"
        "type": "email"
    }
]

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:

{
    "value": "object",
    "label": "Collection or JSON",
    "nested": [
        {
            "name": "metadata",
            "label": "Metadata",
            "help": "Map a Collection or enter JSON in format `{\"key\": \"value\"}` where value can be any type from [Intercom Event Metadata types](https://developers.intercom.com/intercom-api-reference/v1.0/reference#event-metadata-types).\nFor example:\n`{\"order_name\": \"Order123\",\"price\": {\"currency\": \"eur\", \"amount\": 12345}}`\nMaximum 5 entries.",
            "type": "any"
        }
    ]
}

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:

{
    "name": "externalId",
    "label": "External ID",
    "type": "text",
    "advanced": true
}

When you want to make your custom app public and share it with all Make users, your app has to conform to Make standards. Following Make app development standards is a prerequisite to get an app review. Make app standards encompass:

• Custom app functionality.

• Custom app code best practices.

• Testing your custom app with test scenarios.

Check out the following sections to learn more about each prerequisite.

Check your app's functionality

In Make, we develop apps to provide value to our users. Your custom app should use a service that Make doesn't integrate yet. All apps in Make require from the user only credentials that are necessary to create a connection to the service API. If you want to make your custom app public, your app functionality has to follow the same principles:

• Your custom app uses a web service that is not already available in Make.

• Your custom app and it's modules have to connect to a web service API. Avoid duplicating the same functionality as iterators, aggregators or other tools in Make.

• Avoid using APIs that have strong dependencies on other APIs, or APIs that function as redirects to other APIs.

• Avoid using APIs that don't have their own domain, or have their domain associated with service platforms like Heroku or AWS.

• Your custom app has to use only credentials that the service requires to create a connection. Don't request any additional credentials from the user.

Check your app's code

When developing a custom app in Make, you should first go through our Best Practices guide and apply them to your code. By following our best practices, you will ensure that the review and publication process of your app is as smooth as possible.

Before sending an app for review, check that:

• The base and connection have sanitization of sensitive data, e. g. API key or token.

• The base and connection have error handling.

• The base and connection use an endpoint in the app's API.

• Connection is using a correct URL. If the user uses incorrect credentials, they get an error.

• Modules have correct labels and descriptions.

• The app has a universal module.

• All modules have the correct interface depending on the output from the module.

• All dates are formatted or parsed in the mappable parameters and interface.

• Search modules, trigger modules and RPCs have limit parameter.

• Search modules, trigger modules and RPCs have the pagination, if it's supported in the service API.

Create test scenarios

After you check the code of your custom app, you have to create test scenarios to show that the custom app works. Use each module of the custom app in at least one testing scenario.

Best practices for test scenarios

In order to help us with a review of your app, please, follow the best practices.

• Do not use scenarios with another app's webhook.

• It is best to have all modules in one scenario and run them all without an error. You can group your modules via the entity or create scenarios of the way, the endpoints work together, e.g. Create a Task > Create a Subtask (in order to create a subtask, the task has to be created first).

• Try to put all app's modules in one scenario and run the scenario without errors. Connect the app modules based on the object the modules work with or the action the modules do. For example, Create a Task > Create a Subtask (in order to create a subtask, the task has to be created first).

• Put the search and list modules at the end of separate scenario routes to avoid multiple runs of the subsequent modules.

• Run your search and list modules to have logs with pagination. If you don't know how to test pagination, follow the steps here.

• Create a separate scenario that produces an error message. Run the scenario to get an error:

Run the test scenarios right before you request the custom app review and every time you fix issues. The scenario execution logs have a data retention limit and the reviewer won't be able to access old logs.

Options RPC

The most common use is the replacing of a select parameter with static options to select parameter dynamic options. Thanks to RPCs, we are able to retrieve a list of all available options right inside the parameter, according to the user's perspective.

Fields RPC

There are web services, which allow users to have their own structure of data. Therefore, it is needed to make the mappable parameters semi-dynamic, e. g. support custom or dynamic fields.

Samples RPC

The purpose of this RPC is to retrieve sample data dynamically for a module. Replaces hard-coded samples, which might become outdated quickly.

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.

1. A dialog window asking whether should be included or not will pop up.

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

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.

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:

   1. Input example. You can either type it manually or use debug() inside the IML function on Make and copy input from the developer console of your browser (more about debug() ).

   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

7. If you're interested to explore VSC debug tool check their docs .

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

Names of modules follow . Only the first word is capitalized.

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:

Abbreviations

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

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.

You can do it by mapping only the parameters, which are allowed, see the . Or you can implement IML function, see below.

IML Function

Suppose you want to retrieve all users, that are registered on your service. You can’t use , because it returns only a single result. You will have to create a module for this.

The communication for is the same as for Action, except Search has an directive, which specifies where are the items located inside the body.

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:

Iteration and pagination

An module should never contain pagination or the iterate directive. If you need to return multiple objects, create a module instead.

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.

This can be achieved by setting up the parameter in the response. By default, this parameter is added to the Trigger (polling) modules and should be required. In Search modules, this parameter should NOT be required so if a user leaves it empty, the Search modules return everything. Its default value should be set to 10.

Search module limit example:

Use cases of RPCs

Remote procedures are used to get live data from a service. More information about remote procedures can be found .

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.

When Make approves your custom app any Make user can use your custom app. You have to maintain the app to keep the app working. That involves:

• updating the custom app when a relevant part of the service API changes

• fixing bugs the users report

• submit API checkups

• checking feature requests on the Make Idea Exchange regularly

When you maintain the custom app actively, the users can use the app with confidence. The users don't have to worry that their scenarios stop working with new service updates.

Fix reported issues

When a user reports an issue, Make validates the issue. If the issue is valid, we contact you via e-mail with a request to fix the reported issue.

API Checkup

Make sends you a request to update the custom app's API checkup every six months. The Make API checkup helps you and Make to:

• watch changes in API and API's docs

• make sure the app is up-to-date

• manage deprecations of endpoints or API

• manage new versions of the API

• inform users about shutdowns and other cases in advance

The API checkup form contains the following data about the service API:

Feature requests on Make Idea Exchange

When Make users miss a feature in an app, they can submit a new request to . We recommend you check the list of feature requests for your app regularly and respond to them. You can use the search bar for listing requests which mention your app.

Base URL is the main URL to a web service, which should be used for every module and remote procedure in an app, e.g. https://mywebservice.com/api/v1.

There might be situations, when you need to have a variable base URL, e.g. if your web service, which you are integrating, uses multiple domains, and you want to let your users to have access to the one they use.

Example 1

Here, is an example of how to handle 2 types of accounts - sandbox and production.

1. First, add a checkbox in your connection parameters, which can be checked when the condition is met.

2. Then, both in the connection and the base, there should be a condition implemented:

3. All modules and remote procedures then can use hard-coded "url": "/uniqueEndpoint".

Example 2

Here, is an example of how to handle 2 types of accounts - eu and us.

1. First, you need to set up select in your connection parameters, where you let your users choose from available environments:

2. Then, both in the connection and the base, there should be the environment mapped:

3. All modules and remote procedures then can use hard-coded "url": "/uniqueEndpoint".