Make API documentation

Introduction

Fundamentals

The Make REST API allows using HTTP requests to access Make data and control the Make platform without opening its graphical interface. This allows you to embed Make features into your software, add features on top of the platform, and automate your tasks that you perform in Make. To use the Make API, you need an Make account. Once logged in, you can generate an authentication token and start making calls to the API.

The API allows you to interact with multiple Make resources. This documentation covers the following API resources:

• Connections
• Data stores
• Data structures
• Hooks
• Notifications
• Organizations
• Scenarios
• Scenarios folders
• Teams
• Templates
• Users

The following API resources are fully functional, but are not covered in this documentation yet:

• Custom apps
• Devices
• Keys

Make API structure

The root URL of the Make API consists of three parts and looks as follows:
{environment_url}/api/v2/{api_endpoint}

Environment URL
The environment of Make you work in. This can be the link to your private instance of Make, for example, https://development.make.cloud, or the link to Make (with or without the zone, depending on a specific endpoint), for example, https://eu1.make.com.

API version
The version of the API preceded by /api/

Endpoint (with or without parameters)
Each endpoint represents a resource that you can work with. Endpoints contain required and/or optional parameters. The resources are described in detail in Make resources.

HTTP methods

Make API uses standard HTTP methods to interact with endpoints. The following table lists the available HTTP methods and shows examples of endpoints these methods can be used with.

GET

POST

PUT

PATCH

DELETE

Rate limiting

Make API limits the number of requests you can send to the Make API. Make sets the rate limits based on your organization plan:

• Core: 60 per minute
• Pro: 120 per minute
• Teams: 240 per minute
• Enterprise: 1 000 per minute

If you exceed your rate limit, you get error 429 with the message: Requests limit for organization exceeded, please try again later.

Read more about Make pricing.

Getting started

This start guide will take you through making your first request to the Make API.

Example:
Let's imagine that you would like to list all data stores available in your team. Your team ID is 35. Returned data should be ordered in descending order.

To make your first API call, you need to perform the following actions:

curl --location \
--request GET 'https://eu1.make.com/api/v2/data-stores?teamId=35&pg%5BsortDir%5D=asc' \
--header 'Content-Type: application/json' \
--header 'Authorization: Token 93dc8837-2911-4711-a766-59c1167a974d'

{
  "dataStores": [
    {
      "id": 15043,
      "name": "Old data store",
      "records": 10,
      "size": "620",
      "maxSize": "1048576",
      "teamId": 35
    },
    {
      "id": 13433,
      "name": "New data store",
      "records": 1,
      "size": "48",
      "maxSize": "1048576",
      "teamId": 35
    }
  ],
  "pg": {
    "sortBy": "name",
    "limit": 10000,
    "sortDir": "asc",
    "offset": 0
  }
}

Authentication

Make roles and API scopes

Accessibility of Make API endpoints differs depending on the Make platform you use. On Make and our hosted cloud version, regular users cannot access the administration interface. Administration API resources are meant only for internal Make administrators.

In the on-premise version, any user with a platform administration role assigned can access the administration interface. These users can also access API endpoints that are meant for administrators.

Access to the Make API resources depends also on the scopes assigned to the authentication token. Some resources require more than one scope. There are two types of scopes-read and write.

Read scope :read
Allows you to use the GET method with endpoints, usually to get a list of resources or a resource detail. No modification is allowed.

Write scope :write
Allows you to use the POST, PUT, PATCH, or DELETE methods with endpoints to create, modify, or remove resources.

Administration scopes (only for administrators of Make White Label platforms)

Administration

• admin:read
  • Allows getting all resources and information available only to administrators — all resources that are available in the administration interface, such as collections of all created users, templates, scenarios, and custom and native apps for the whole platform and all their details.
• admin:write
  • Allows performing all actions available only to administrators — all actions that can be performed in the administration interface, such as creating organizations, deleting approved templates, reviewing custom apps, creating and deleting new users, overwriting scenarios and templates settings.

Native apps

• apps:read
  • Allows getting a collection of all native apps.
  • Allows getting details of a native app.
• apps:write
  • Allows updating a native app.
  • Allows deleting a native app.

System settings

• system:read
  • Allows reading the Make platform settings.
• system:write
  • Allows modifying the Make platform settings.

Standard user scopes (for all users of Make platforms)

Connections

• connections:read
  • Allows retrieving connections for a given team.
  • Allows getting details of a connection.
• connections:write
  • Allows creating new connections.
  • Allows updating connections.
  • Allows deleting connections.
  • Allows setting data for connections.
  • Allows verifying connections.
  • Allows checking if a connection scope is limited.

Custom property structures

• custom-property-structures:read
  • Allows retrieving the list of custom properties structures in the organization.
  • Allows getting custom properties items.
• custom-property-structures:write
  • Allows creating custom properties structures.
  • Allows creating custom property structure items.
  • Allows updating custom property structure items.
  • Allows deleting custom property structure items.

Data stores

• datastores:read
  • Allows getting all data stores for a given team.
  • Allows getting records from a data store.
• datastores:write
  • Allows creating new data store.
  • Allows updating data stores.
  • Allows deleting data store.
  • Allows modifying the records of a data store.

Devices

• devices:read
  • Allows retrieving all devices for a given team.
  • Allows getting details of a device.
• devices:write
  • Allows creating new devices.
  • Allows updating devices.
  • Allows deleting devices.

Incomplete executions

• dlqs:read
  • Allows getting all incomplete executions of a given scenario.
  • Allows getting details of an incomplete execution.
  • Allows getting bundles, blueprints, and logs of an incomplete execution.
• dlqs:write
  • Allows updating incomplete executions.
  • Allows deleting incomplete executions.

Custom functions

• functions:read
  • Allows getting data about the custom functions which belong to the team.
  • Allows getting the history of updates to the custom functions.
• functions:write
  • Allows creating custom functions.
  • Allows updating custom functions.
  • Allows deleting custom functions.

Hooks

• hooks:read
  • Allows getting all hooks (mailhooks and webhooks) for a given team.
  • Allows getting hook requests.
  • Allows checking if a hook is active.
• hooks:write
  • Allows creating new hooks.
  • Allows updating hooks.
  • Allows deleting hooks.
  • Allows enabling or disabling hooks.
  • Allows starting or stopping the automatic determination of a data structure for a hook.
  • Allows setting data for hooks.

Keys

• keys:read
  • Allows getting all keys for a given team.
  • Allows getting key types.
• keys:write
  • Allows creating new keys.
  • Allows updating keys.
  • Allows deleting keys.

Notifications

• notifications:read
  • Allows getting all notifications for a given user.
  • Allows getting details of a notification.
• notifications:write
  • Allows marking notifications as read.
  • Allows deleting notifications.

Organizations

• organizations:read
  • Allows getting all organizations to which the authenticated user belongs.
  • Allows getting installed apps, invitations, user roles, and basic details of organizations.
• organizations:write
  • Allows creating new organizations (only for admins).
  • Allows updating organizations.
  • Allows deleting organizations.
  • Allows accepting invitations to organizations.
  • Allows adding members to organizations.
• organizations-variables:read
  • Allows getting data of organization variables to which the authenticated user belongs.
  • Allows getting the history of updates of custom organization variables.
• organizations-variables:write
  • Allows creating custom organization variables.
  • Allows updating custom organization variables.
  • Allows deleting custom organization variables.

Scenarios

• scenarios:read
  • Allows getting all scenarios for a given team or organization.
  • Allows getting details of a scenario.
  • Allows getting properties of triggers included in scenarios.
  • Allows getting scenario blueprints.
  • Allows getting blueprint versions.
  • Allows getting scenario logs.
  • Allows getting scenario folders.
  • Allows inspecting scenario interface.
  • Allows retrieving custom scenario properties data.
• scenarios:write
  • Allows creating new scenarios and scenario folders.
  • Allows updating scenarios and scenario folder.
  • Allows cloning scenarios.
  • Allows verifying whether module settings are set or not.
  • Allows activating and deactivating scenarios.
  • Allows deleting scenarios and scenario folders.
  • Allows updating scenario interface.
  • Allows adding custom scenario properties data.
  • Allows updating custom scenario properties data.
  • Allows deleting custom scenario properties data.
• scenarios:run
  • Allows running scenarios with the API.

Custom apps

• sdk-apps:read
  • Allows getting all custom apps for the authenticated user.
  • Allows getting information from specific configuration sections of a custom app.
  • Allows getting invitation details for an app.
• sdk-apps:write
  • Allows creating custom apps.
  • Allows managing configuration of custom apps.
  • Allows cloning custom apps.
  • Allows requesting review of custom apps.
  • Allows rolling back changes made in custom apps.
  • Allows uninstalling custom apps from organizations.
  • Allows deleting custom apps.

Teams

• teams:read
  • Allows getting all teams that belong to a given organization.
  • Allows getting details of a team.
  • Allows getting all team roles.
  • Allows getting details of a team role.
• teams:write
  • Allows creating new teams.
  • Allows updating teams.
  • Allows deleting teams.
• teams-variables:read
  • Allows getting data of team variables to which the authenticated user belongs.
  • Allows getting the history of updates of custom team variables.
• team-variables:write
  • Allows creating custom team variables.
  • Allows updating custom team variables.
  • Allows deleting custom team variables.

Templates

• templates:read
  • Allows retrieving all private templates for a given team.
  • Allows getting all public templates.
  • Allows getting private or public template details.
  • Allows getting private or public template blueprints.
• templates:write
  • Allows creating new templates.
  • Allows updating templates.
  • Allows deleting templates.
  • Allows publishing private templates.
  • Allows requesting approval of published templates.

Data structures

• udts:read
  • Allows retrieving all data structures for a given team.
• udts:write
  • Allows creating new data structures.
  • Allows updating data structures.
  • Allows deleting data structures.
  • Allows cloning data structures.

Users

• user:read
  • Allows getting all users who belong to a given team or organization.
  • Allows getting API authentication tokens assigned to the currently authenticated user.
  • Allows getting organization invitations assigned to the currently authenticated user.
  • Allows getting organization invitations assigned to a user.
  • Allows getting organization and team roles that can be assigned to any user.
  • Allows getting a number of unread notifications for the currently authenticated user.
  • Allows getting organizations invitations for a user.
  • Allows getting details of an invitation to an organization for a user.
  • Allows getting details of a notification assigned to a user in a given team.
  • Allows getting team roles of a user.
• user:write
  • Allows setting a user role for a given team.
  • Allows setting a user role in a given organization.
  • Allows transferring organization ownership to a user.
  • Allows updating a notification for a user in a given team.
  • Allows creating a new API authentication token for a currently authenticated user.
  • Allows deleting an API authentication token identified by timestamp for a currently authenticated user.
  • Allows deleting an account of a currently authenticated user.
  • Allows updating details of a user.

Generating authentication token

Make API uses authentication tokens to authenticate requests. You must include your authentication token in the headers of all requests that you send to the API.

Generate and manage API tokens from your profile in the Make interface.

Make generates your token. Copy it and store it in a safe place.

Do not share your token with anyone!

With an active token, you are ready to make API calls. For more details, refer to the Getting started section.

Managing authentication token

After you generate your authentication token and open the API tab in your profile again, you can no longer change the token or the scopes assigned to the token. You can only view the initial part of the token value and view the scopes.

To manage your tokens:

Since editing the token is not possible, you can always delete the old token and replace it with a new one. You will need to do this if you decide to add or remove scopes from your authentication token.

Pagination, sorting and filtering

The majority of responses containing a collection of resources are paginated. Pagination limits the number of returned results per request to avoid delays in receiving a response and prevent overloading with results. Thanks to pagination, the API can run at its best performance.

You set pagination, sorting, and filtering parameters in query parameters. Separate multiple query parameters using the & symbol. The order of the parameters does not matter.

Pagination and sorting

pg[limit]
Defines the maximum number of results to return. For example, pg[limit]=100. The default value varies with different resources.

pg[offset]
Defines the number of results you want to skip before getting the results you need. For example, pg[offset]=10. The default value for most endpoints is 0.

pg[sortBy]
Defines the property by which to sort results. For example, pg[sortBy]=id. By default, results are usually sorted by name or id.

pg[sortDir]
Defines the sorting order. Use asc for ascending order, use desc for descending order. The default ordering direction is usually ascending.

Example
Let’s say we want to retrieve data stores that belong to the team with ID 212.

Filtering

Use the cols[] parameter to select values you want in the response. You can also use the cols[] parameter to get values that the endpoint does not return by default. The set of available filtering values is different for each endpoint. Check the example API call responses to see what data you can get from the API call.

Specify the cols[] parameter multiple times in the API call to get multiple values from the endpoint. You can put numbers in the brackets to specify order in which you want to list the values in the API call response.

Example: Get only the name, id and teams in the specified organization. List the data in order: name, id, teams.

Some endpoints have specific filtering parameters. For example, in the /templates endpoint you can use the usedApps[] parameter. The usedApps[] parameter allows you to get only the templates containing specific apps.

Troubleshooting and error handling

HTTP status codes of errors

This article describes the most frequent error codes returned by the Make API. If you need help resolving common issues related to the Make API, refer to the Troubleshooting section. If your request is incorrect, in the response, you can find the details of the error that should help you to troubleshoot. All Make API errors have the same schema. Below you can see the example of a response for the request with the incorrect parameter. This can happen, for example, when you request a resource you do not have access to:

Example:

{
  "detail": "Access denied.",
  "message": "Permission denied",
  "code": "SC403",
}

Standard error responses

Troubleshooting

This section describes most common mistakes that result in API-related problems, such as receiving Access denied or Not found errors. You can also refer to the HTTP status codes of errors for more details.

Using HTTP instead of HTTPS in the URL

Use HTTPS at the beginning of the URL in your request. This is required for security reasons.

Using an incorrect environment

If you have access to more than one Make environment, ensure that you use the correct environment in the URL and that you use a valid authentication token generated for this specific environment.

Using an incorrect endpoint

Ensure there are no empty or white spaces in the endpoint URL and that there are no backslash symbols at the end of the URL after the endpoint name.

Missing authentication details or using incorrect authentication details

Ensure that you are using the correct authentication details. To make a successful request, you need to have the correct authentication token with the correct scopes assigned to it.

Note that you need a separate token for each Make environment.

Missing access to the requested resource

Ensure that scopes assigned to your authentication token correspond to the requested resource.

Note that you cannot access administrator resources if you are a regular Make user.

Missing required parameters or using invalid or improperly formatted parameters

Many endpoints require at least one mandatory parameter. Often it is the teamId or an ID of the specific resource. Do not forget to add the required parameters to the request. Also, note that query, path, and pagination parameters need to be properly formatted. The first query parameter should start with a question mark. Separate parameters with the ampersand symbol. Some special characters, for example, in the pagination parameters, need to be encoded when used in URLs.

Sending an invalid or improperly formatted request body

The structure of the API request body must conform to the JSON schema standard. You can use JSON validators available on the internet to validate your request body before sending it.

Resources

API resources are grouped into sections corresponding with Make features and components.

Each endpoint resource contains the following details:

Methods and endpoints

Methods define the allowed interaction and endpoints define how to access the resource — what URI should be used to interact with a resource.
Example: GET /data-stores

Required scopes

Defines what resources you are allowed to interact with based on scopes you selected when generating your API access token.
Example: datastores:write

Resource description

Describes the expected outcome when using an endpoint, and what Make features the resource relates to.

Parameters

These are options you can include with a request to modify the response. Each parameter specifies whether it is required or not. Parameters are divided into two main groups:

• Path parameters — path parameters are always required. They are used to identify or specify the resource (usually by indicating its ID) and they should be placed inside the endpoint URI. Example: /data-stores/54

• Query parameters — query parameters are often optional. They can be used to specify the resource but they are usually used as parameters to sort or filter resources. They are placed at the end of the endpoint URI, after a question mark. Separate multiple parameters with an ampersand symbol. If a parameter contains square brackets, encode them. Example: /data-stores?teamId=123&pg%5Boffset%5D=10

• Request body — for some endpoints (mainly connected with the POST, PUT, or PATCH HTTP methods), you can also see the Request body section in the endpoint details. This section contains the description of the payload properties that are needed to modify the resource.

  Example:

  {
    "name": "Customers",
    "teamId": 123,
    "datastructureId": 178,
    "maxSizeMB": 1
  }

Request examples

These are request samples that show how to make a request to the endpoint. They consist of the request URL and authentication token (if needed) and other elements required to make a request in the selected language. Example of request for creating a data store:

Response examples

These are response samples you would receive when calling the request in real life. The outcome strictly depends on the request sample. The response schema contains all possible elements available in the response. Each response has its status code. Example of created data store:

curl -X POST https://eu1.make.dev/api/v2/data-stores \
--header 'Content-Type: application/json' \
--header 'Authorization: Token 93dc8837-2911-4711-a766-59c1167a974d' \
-d '{"name":"Customers","teamId":123,"datastructureId":1234,"maxSizeMB":1}'

{
  "dataStore": {
    "id": 20024,
    "name": "Customers",
    "teamId": "123",
    "datastructureId": 1234,
    "records": 0,
    "size": "0",
    "maxSize": "1048576"
  }
}