If you need to interact with a third-party application in Make and there is not an app created for it yet, you can make your own.

This documentation helps you prepare to build an app, walks you through the process of creating your first app, and provides you with best practices and specifications for your project.

Get started

Step 1: Select your editor

you want to use to build your custom app:

• or

• with vibe coding (information coming soon)

Step 2: Determine your starting point

• If you're already familiar with Make, you're ready to .

• If you're new to Make, we recommend that you begin with a practice exercise (see ).

Step 3: Practice connecting an API in Make

Before creating your first app, to practice connecting to your selected API on the Make platform. This will help you get comfortable with the process.

You can build a custom app in Make in a variety of ways.

Here we show two methods: through the Make web interface or with vibe coding.

Make web interface

The lets you create and manage the custom app configuration directly within the Make platform. It offers a graphical interface, allowing you to easily build the app by setting up connections, modules, and parameters and personalizing the app behavior.

In this section, you will learn the naming conventions used for modules in an app.

• Module names

• Module labels

• Module descriptions

In this section, you will learn the naming conventions used for input parameters of an app.

• Parameter labels

• Parameter hints

In this section, we will walk through the steps to create a custom app.

The information found here corresponds with the content of the Get started with custom apps online course and serves as an additional resource.

To create your first app, you will:

• Complete the initial setup in Make

In this section, you will learn the best practices for developing custom apps.

• Naming conventions

• Input parameters

• Output parameters

Module names are unique identifiers for each module in your app.

They are internal names and differ from the module labels that a user sees when using the app.

Module names:

• must be between 3 and 48 characters long

• must match pattern /^[a-zA-Z][0-9a-zA-Z]+[0-9a-zA-Z]$/

Static parameters are only used for trigger modules.

For all other modules, the Static Parameters tab is no longer applicable and should be left empty. All fields should be added in the Mappable Parameters tab instead.

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

{
    "baseUrl": "https://www.example.com/api/v1",
    "headers": {
        "Authorization": "Bearer {{connection.accessToken}}"
    },
    "response": {
        "error": {
            "message"

If there are multiple types of connection, use parentheses for the connection type specification:

Bulk action modules can perform an action on multiple records in a single call.

To use bulk action modules, the user needs to create an array of records and map the array into the bulk module.

• In the bulk module UI, the mapping should always be turned ON by default.

• Types of output:

  • If the response returns a single success / fail, the module should be an action module.

  • If the response returns an output bundle of success / fail for an individual record, the module should be a search module.

• If possible, bulk modules should output the updated range/rows.

For more information for labeling and describing bulk action modules, see the best practices guide to and .

On the Custom Apps page, click on your app to view the Make app environment for your custom app.

Across the top you will see eight tabs.

In this overview, we will focus on the app's main components:

To test your app in Make, create a new scenario.

Every app in 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.

During the development of your app, you may experience issues with your app and/or API. Therefore, you will need to use the to debug your app.

Here are some examples of specific debugging issues you may encounter:

With you can debug your Make scenarios by adding an extra pane to the . Using this new debugger pane, you can check all the manual runs of your scenarios, review all the performed operations, and see the details of every API call performed. Additionally, you can see which module, operation, or response caused an error in your scenario.

Install Make DevTool

To install Make DevTool:

Live Stream displays what is happening in the background once you've hit the Run once button.

You can 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, request headers, and query string)

• Request Body

The Scenario Debugger shows you the historical logs of your scenario, including the history of the scenario runs. You can search for modules by their name or ID.

Search for modules

To search for the module by name or ID number, enter the search term in the search field in the left panel of the DevTool.

When you create a custom app, you can use it any time. When you finish developing and testing your app, you might share the app with selected users with an invite link.

If you want to share your custom app with all Make users, we have created an app review process to ensure that your app meets our app standards.

Prerequisites

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

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 , Make will publish your app and make the app available to all Make users. Otherwise, the Make QA team will contact you with instructions for how you should improve your custom app.

You can check the status of your custom app review in the App flow tab. The App flow tab contains a list of apps under review, their status, 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 will see 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.

When Make approves your app, your app becomes available to all Make users in their scenarios. To the users, an app developed by Make looks the same as the app developed by you. You need 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 is published, 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:

Follow these conventions when naming your app:

• Start with your brand guidelines as the primary reference.

• When uncertain about naming conventions, use .

• If your app name requires suffixes, use title case for the suffix as well.

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

Consider the following when you decide the order of groups and modules in your app:

• Triggers

  • All instant triggers

  • All polling triggers

In this section, you will learn best practices regarding the interface and how to process output parameters.

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

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

The Base section should also have and that is common for all modules. The authorization should use the API key, access token, or username and password entered in the connection. The sanitization should hide all these sensitive parameters.

We recommend allowing users to after they create them. Updating a connection simplifies scenario and user credential maintenance when there's a change in the user's organization.

To allow users to edit a connection:

In this section, you will learn best practices for the following regarding modules:

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.

You should always make sure the existing scenarios.

Consider this as the base:

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

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

Changes

In custom apps that haven't been approved by Make, it's 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 the VS Code extension and store the files on GitHub or any similar tool.

All changes take effect immediately. Before saving a change, make sure it will not negatively affect existing scenarios.

Every connection should have a way to check if the used API key (token) is valid (a validation endpoint).

This means that each connection should have a part that uses the API key (token) against an endpoint that requires only the API key to run. For example, a user info endpoint, or any endpoint that is used to list data.

The validation endpoint is located:

• OAuth1 and OAuth2 - in the info directive

• API key, basic auth, digest auth, other - in the url

Action modules are straightforward modules that make one or more requests and return a single bundle as result. Each execution is isolated, so they do not have a state like polling triggers and they can't be used to output multiple bundles like search modules. You should use an action module when the API endpoint returns a single item in the response. Some examples of common action modules include:

• Create an object

• Update a user

• Delete an email

• Get a record (by its ID)

• Download/Upload a file

The custom apps 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 components

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

Component blocks

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

For example, parameters (static or mappable) are available everywhere apart from Base and Functions. Meanwhile, common data exists only inside Base and Connection.

Information detailing these blocks can be found in the .

Block elements

are like bricks for component blocks. A block doesn't exist without these elements. Multiple elements form a block.

Pick a brick that suits your needs. You can use multiple, separated components or combine them together using the nested property.

To set up your custom app for Geocodify:

You can now see your custom app listed on the Custom Apps page where you can view the to continue with the setup of the , , and for your app.

Private app

A private app can only be used by the author of the app until the app is installed in an organization to which the author and other users have access.

A private tag is displayed after your app's name on the app's page.

Deletion of a private app

If your private app is not used in any of your scenarios, you can delete the private app.

Deletion of a module

You can delete a module for a private app only if it is not used in any scenario. If you try to delete a module used in a scenario, you will see a warning dialog with a request to remove the module from the scenario first.

Deletion of a webhook, connection, RPC, or custom IML function

You can delete a webhook, connection, RPC, or custom IML function only if it is not used in any module. If you try to do so, you will see a warning dialog in the lower-right corner.

Public app

If you want to share your app outside of your organization, you need to publish your app to generate an invite link.

Go to your app and open your app's page. Click Publish in the right upper corner.

Once you publish the app, the invite link is generated. You can share it with any other Maker who will then install it in their organization. It doesn't matter where the organization is located (EU1 or US1).

Deletion of a public app

If you wish to have your public app deleted, and we will remove the app from your account.

Deletion of a module, webhook, connection, RPC, or custom IML function

We recommend you change the component's label to indicate that the component should not be used, e.g. [DO NOT USE] My unwanted module. Make sure the module is hidden.

Distribution control of modules

If you actively share your public app via an invite link, you can control the distribution of modules that you have in your public app by making them hidden/visible.

If you hide an already visible module that is currently in use in a scenario, the module will continue working in the scenario. However, the hidden module will not be available in the app selector in a new scenario.

Approved app

Approved apps are available to any user in Make. If you want to have your app available to all Makers, review the to ensure that your app follows best practices.

Once you make sure your app follows our conditions and best practices, you can .

If the app , it becomes available for everyone to use. That mean's that any user on Make can add your app to his/her scenario and use it.

If the API supports pagination, it should be implemented. To test that the pagination works as intended, we recommended you set the page size to a low number, if possible.

{
    "url": "/contacts/filters/{{parameters.filter_id}}",
    "method": "GET",
    "qs": {
        //"per_page": 100
	"per_page": 10 //set value for testing
    },
    

Create test records

Next, create as many records to equal one page and a few more.

Use the Flow Control > Repeater module to do this, which also returns the ID of the repeat.

Map this ID in the following module to differentiate the records.

Once the test records are created, you can test your search module.

Test search module

With the help of the ID from the repeater, you can see if the records are ordered and how, and whether the records are correctly retrieved (for example, they are not being duplicated).

In the console, you can also 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 see them.

To debug your IML functions, output the code and use a tool of your choosing.

Output a message to the dev 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 are visible inside the console of your browser.

Debug the JavaScript snippet

To debug the output, you can use a variety of tools. Search online to find a JavaScript debugging tool that you prefer.

Here are some to choose from:

In this section, you will learn the naming conventions used for elements of an app.

• Apps

• Modules

  • Module names

Parameter (input field) labels should be clear and easy for users to understand. Consider the following when creating input field labels:

• Give a short description (1–3 words) of the requested input.

• Match the terminology that users see in the third-party’s UI, not the API documentation.

• Be descriptive, not instructional. If the selection needs more explanation, include information in the help text below the field.

• Use . The following should be capitalized:

  • The first word of the label

  • Proper nouns and trademarks. For example, names of people, companies, products, or other proper nouns

  • Official or trademarked terms

  • Acronyms. For example, Content ID, File URL

• Avoid punctuation and articles (the, an, a).

Parameter label examples

Parameter label for fields with a Map toggle

For select fields, the label of the field should be dependent on whether the Map toggle is ON or OFF by default.

If the Map toggle is ON by default, the field label should contain "ID".

If the Map toggle is OFF by default, the field label should NOT contain "ID".

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

You can generate an interface using our Interface Generator.

Dynamic interface according to user-defined fields

Retrieving all fields from the endpoint could be difficult, especially when integrating an ERP or other business-related backend that has hundreds of fields.

The solution to this varies across different platforms, but they are similar.

One method is to use a select parameter to retrieve only the fields that you need. For example, .

We recommend you use the metadata parameter to store the account's name or email. This allows users to easily distinguish their stored connections.

Always save the metadata in the connection if:

• the endpoint that can obtain the authenticated user’s information is available, and

• the information provided is able to distinguish the connection.

Saving the metadata allows for better identification on the Connections page.

We suggest saving the following information:

• Name

• Email

• User ID

• Organization, Company, Location, etc.

The Make an API Call module connection will not work if the required scopes of the endpoint are not in the OAuth connection. To correct this, allow users to define additional scopes when they create a connection.

Make an API Call parameters: non-editable connection

{
	"type": "banner",
	"text": "Your connection must contain the required scopes for your API call. If you receive an error, create a new connection with the necessary Additional scopes.",
	"theme": "info"
}

Make an API Call parameters: editable connection

Connection parameters

Connection communication

Make web interface

After you save a change in an approved app, a new Changes tab is available. On this page, there is a list of all changes available in the particular app.

After clicking on a Diff log, you will see a dialog box informing you about available changes.

For a detailed Diff file, click Show diff button.

You will see a comparison view with the changes that have been made.

VS Code extension

After you save a change in an approved app, the app is marked with a * next to the name. Every module with blocks where the changes are available is marked with a * as well.

To view changes, right click the item and select the Show changes option.

You will see a comparison view with the changes that have been made.

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 documentation as well as in the best practices guide to module descriptions.

Universal modules

Each app should have a universal module. This module allows users to use API endpoints that are not supported, using their connection created to the app.

More about universal modules can be found in our documentation.

Make sure the universal module has the:

• correct label and description,

• correct url which starts with the , and

• correct connection.

An error with the status code 429 is an API rate limit error.

However, the default module error type for an error code between 400 - 500 is always a RuntimeError.

There are advantages to handling a 429 error as a RateLimitError instead.

RuntimeError handling vs RateLimitError handling

In a scenario with scheduling turned on, if one of the scenario modules throws a RuntimeError, your scenario will break and retry to run according to the number of consecutive errors from your scenario settings (the default is 3 times).

If the number of consecutive errors is consumed, the scenario scheduling will be switched off and you will need to manually switch your scenario scheduling on again.

To prevent this, use the module error type RateLimitError to handle the 429 error. This error type has the same functionality as ConnectionError and returns the warning message instead of the error sign.

The advantage of using RateLimitError is that, instead of using the number of consecutive errors and then switching the scheduling off, the retries continue with .

For example:

• A scenario with scheduling turned on suddenly has one module throw a RateLimitError.

• It will retry after 1 minute.

• If it throws the RateLimitError again, it will retry after 2 minutes.

After 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

• submitting API checkups

• checking feature requests on the Make Idea Exchange regularly

If you actively maintain the custom app, users can use the app with confidence. The users don't have to worry that their scenarios might 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 email 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

Please ensure your integration is kept current with the latest API.

If the Make integration is not actively maintained, we reserve the right to assume ownership of the custom app to ensure uninterrupted service for its users.

Feature requests on Make Idea Exchange

When Make users miss a feature in an app, they can submit a new request to the .

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.

Sanitization protects sensitive data (passwords, secret keys, etc.) from leakage.

You should always sanitize the log so no personal tokens and/or keys are leaked.

If you don't use sanitization, the request and response logs will not be available in the console.

...
"log": {
        "sanitize": ["request.headers.accesstoken"]
    }
...

Base URL is the main URL to a web service that 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. For example, if the web service uses multiple domains you may want to let your users have access to the one they use.

Base URL example: two types of accounts

This is an example of how to handle two types of accounts - sandbox and production.

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

Base URL example: two environments

This is an example of how to handle two types of accounts - eu and us.

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

Types of dedicated webhooks

Attached

For an , the new URL address that is created is automatically registered to the service using an attach procedure and can be unregistered using detach procedure.

If there is an endpoint available in the API for registration of the webhook, the attach directive should be implemented.

Not attached

For a , the new URL address that is created has to be registered manually by the user. The user copies the URL address and pastes it to the webhook's settings of the web service.

If there is no attach directive available in the API but the web service allows setting up a webhook manually, implement the dedicated webhook without the attach directive.

The Base component contains the common settings of the app that are inherited by all modules.

The common settings include:

• Base URL: The API base URL used as the main address for all requests to the API.

• Authorization: Authentication information and credentials.

• Error Handling and Sanitization: Same as the Connections component.

Once you make sure that your app meets Make's and follows Make's , you can request an app review:

Request a review

To request an app review:

When maintaining your app, you might need to apply changes or create a new app version.

The process is different between , and .

Changes and versioning in private/public custom apps

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

APIs usually use authentication or authorization to limit access to their endpoints.

Make provides a list of the most common types of connections with prefilled code that can be edited for your needs. In general, you will only need to change the URLs and names of the parameters.

Types of connections

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 request a review of your changes and wait for approval.

To request a review, 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 the 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.

The new URL address for the webhook, created when a user opens the instant trigger and creates a new webhook, is automatically registered to the service using the attach procedure, and can be unregistered using the detach procedure.

Attach

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

In order to activate the shared webhook so it listens to incoming traffic, you must publish your app. Before doing so, please read the to understand how that affects your app.

The new URL address for the webhook, created when a user opens the instant trigger and creates a new webhook, has to be registered manually by the user. The user needs to copy the URL address and paste it to the webhook configuration in the settings of the external platform. The main advantages of webhooks that are not attached when compared to the custom webhook module are:

• Improved UX

  • Mapping is easier when you define an .

  • Ability to modify the output if needed, such as parsing dates in non-standard forms, or un-nesting parameters.

In this section, you will learn best practices regarding different types of input parameters and how to process them.

To find the RPC debug tool:

RPC page

Compare the tabs below to learn how to access information about your RPCs in Make.

Communication tab

After creating a new RPC, you can modify the default template in the Communications tab for your needs.

Parameters tab

By default, the Parameters tab is empty. Here you can add any parameter you need. You can also add mappable parameters from a module. .

RPC debug tool

The RPC debug tool works the same way modules do.

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

2. Click the Test button.

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

You will see the output that you specified in the RPC communication.

If you specified output as "label" and "value" (with the purpose of using it inside a Select parameter), do not expect to see the full server response there.

Debug RPCs in the dev console

Sometimes you may need to look into the request you're sending and the response from the API.

You can see more details about the RPC you're testing by opening your browser's dev console: Network tab.

The debug values show the request being sent and the response received by the API.

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

Review the following sections to learn more about each prerequisite.

Custom app 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 its 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.

Custom app code

When developing a custom app in Make, you should first go through our 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 of sensitive data, e. g. API key or token.

• The base and connection have .

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

• The connection is . If the user uses incorrect credentials, they get an error.

Testing your custom app

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

Best practices for test scenarios

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

• Try to put all of the 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 perform. 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, .

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

It is important to implement error handling in your app so your users clearly understand the cause of the error.

Each service sends an error message when an error occurs. This usually happens when the request has wrong parameters or values or when the service has an outage.

When an error occurs, the module should indicate the error as well as a detailed message that can then be used in filters. The message should be clear and user-friendly. For example, instead of "Error: contact_not_found", your message should be "[404] The specified contact was not found."

The error handling code should correspond to the structure of the server response.

Error handling example

In this example, the JSON response has the following format in cases where something goes wrong:

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

Common error messages

4xx: Client Error

indicate something wrong on the client side.

5xx: Server Error

indicate something wrong on the side of the third-party service.

Handling status code 200

Sometimes the API returns status code 200 with an error in the body. In this situation, use the directive, which tells whether the response should be processed or an error should be thrown.

Sometimes the API returns status code 200 without errors to an incorrect request. This can happen, for example, if the Get a/an [item] module is developed based on the search endpoint and not based on a separate endpoint. This may be the case if a separate endpoint for that action is not implemented on the service’s side.

There's no dedicated JWT connection type because the JWT is a special format of the Authorization header. See the basic connection section for more information.

Generating a JWT

To generate the token, use the following code:

{
  "url": "https://mock.api/connect",
  "temp": {
    "jwt": {
      "iss": "https://iam.the.issu.er",
      "iat": "{{timestamp}}",
      

In this example, you can build a JWT payload inside the temp variable called jwt.

Inside the Authorization header, call the IML function named jwt. The jwt function accepts four parameters:

1. The payload to be signed.

2. The secret to sign the payload.

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

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

There are six basic types of modules:

The Make web interface lets you create and manage the custom apps configuration directly within the Make platform.

Access the Make web interface

To access the web interface:

Now that you have , we recommend completing these first steps before :

are used to retrieve live data from a service for an input field.

You can use RPCs to retrieve dynamic options in a field to clarify the expected input for a user. For example, selecting a country in a dropdown could trigger an RPC to retrieve corresponding states or cities.

In this example, the Priority field provides the expected values (Low, Medium, High, Urgent). In mapping mode, the user has to enter or map the option's ID instead of selecting a value.

A polling trigger checks for new data in a service account since the last scenario run, based on the scenario's schedule.

The polling trigger sends a request to the service. If new data exists, the scenario runs and you see the data in the module’s output as bundles. If not, you see no bundles.

Use a polling trigger only if the results:

• consist of either a numeric ID or a date as the identifier, or

• the results can be sorted or defaulted in descending order.

The Base section is used to set up authorization. Most services require the authorization key be sent either in headers or in the qs (query string). If you set the authorization in the base, all modules and Remote Procedure Calls (RPCs) will inherit it.

Common methods of authorization

An instant trigger is a webhook that starts a scenario whenever new data arrives.

Your app should implement a fully functional instant trigger as a Watch module, even if an API might have endpoints like Get a webhook, List webhooks, or Update a webhook.

Connect metadata

Always save the metadata in the connection if

• the endpoint that can obtain authenticated user’s information is available, and

• the information provided is able to distinguish the connection.

When naming your connection, provide as much information as possible. This provides better identification on the connection page. The following information is suggested:

• Name

• Email

• User ID

• Organization / Company / Location / Tenant