APIs and Make
You know that an API (Application Programming Interface) is a set of rules and tools that allow different software applications to communicate with each other. Endpoints are specific URLs that define where to access a specific API service. Each endpoint corresponds to a particular function or action of the API.
To use an API, you need to read its documentation, which explains how to use the API, how to authenticate, what data is available, how to request it, and what will be the format of the response. You use HTTP to make the request.
In Make, this is much easier. Make offers apps that integrate with third-party services, using modules to call their specific API endpoints.
These modules help you interact with APIs without dealing with the technical details,
making everything nice and easy. The apps are ready for you to use them, no need to worry about a thing!
At the time of writing this course, there are nearly 2,000 apps available in Make (and counting).
HTTP calls
If an app isn’t available in Make, you can still use it in your scenario by using the HTTP modules to interact with an API.
You’ll need to check the documentation, set up the authentication, and include any required information in the request, like headers, query parameters, or body.
Once you send the request to the API endpoint, the app responds with data that you can use in your automation.
Using HTTP modules gives you the flexibility to include APIs that aren’t available in Make
in your scenarios. However, it comes with some limitations: 1 HTTP calls are not easy for beginners. Setting up HTTP calls in Make can be hard for people without technical knowledge. You need to understand API documentation, set up the authentication, and define all the parameters for the call. This is more complicated and less intuitive than using apps already present in Make, which simplify these steps with pre-built configurations.
2 You might have to set up the same call in different scenarios. If you use the same API in multiple scenarios, you will have to set up the HTTP call in each of them. It’s not the end of the world and you can do it, but for sure you can think of a better use of your time.
3 You can’t filter or change the data you get. HTTP calls return all the data the API sends. Even if you only need a small part, they don’t allow you to filter or personalize the API response. For example, if you use OpenWeatherMap, you’ll get a lot of weather details, even if you just want the temperature. If the API doesn’t let you filter, you’ll have to go through the data and pick out what you need. You basically have to live with it.
4 Handling pagination is not automatic. Some APIs split their data into multiple pages. With HTTP calls, you need to manually add extra steps to get all the data. This involves adding modules to handle pagination parameters and retrieve all data, as brilliantly explained in the course Pagination - retrieving all data from APIs. It is doable, but it will require more time to set it up, and you will use more operations when running your scenario, because of the additional modules that handle pagination.
5 Complex authentication methods are harder to set up. OAuth2 Authorization Code flow is easier to implement because Make has a built-in module for it. But other types of authentication can be more complex to implement from scratch and you might need to make multiple HTTP calls to get it working. For example, a token-based authentication, where you first get a token by logging in and then use it for other calls, can be done but requires multiple HTTP calls. 6 Credentials and sensitive data might not be protected. For example, if you’re setting up a multi- step authentication using the HTTP> Make a request module, your credentials will appear in the history logs. At the moment, there’s no way to hide it.
Custom apps
You can take it a step further and build your own custom app. A custom app is an app that you build yourself, similar to the ones already available in Make. It connects to the API you choose and has the specific features or actions you need.
In your custom app, you basically set up HTTP calls to the API’s endpoints, allowing you to have more control over customizing both the call and the response.
Everything you need to build a custom app is an API. You’ll need to check the API documentation to get all the details to set up the request, like authentication, base URL,
endpoints, methods, and parameters. Once you have this information, you can use it to create your custom app. This course will guide you through the process of building your first custom app.
Once created, you can use it in your scenarios and share it with others. Later in this unit, you’ll learn more about how to make your app available and who can access it.
Note that to use your custom app you need to be able to install it in your Make organization. To do this, you must have one of the following roles in Make: Owner, Admin, or App Developer.
about these roles.
Why use custom apps?
Here are some advantages of using custom apps:
1 Non technical users don’t need to set up complex HTTP calls. If you have non-technical team members, they won’t need to read API documentation or set up HTTP calls. You can do the setup for them, and they can simply use the app directly in the scenario editor, making their life (and yours) way easier.
2 You don’t need to repeat the HTTP call setup in multiple scenarios. If you call the same API across multiple scenarios, you can build a custom app and use it whenever you need it. The custom app eliminates the need to redefine the HTTP call parameters and settings in every scenario. It saves time, ensures consistency, and makes a better use of your time.
3 You can filter or personalize the API response. With a custom app, you can define which information from the data your API returns to share with the scenarios by filtering, setting a specific output, and organizing the data. This makes it easier to get just the information you want, and use it in the next steps of your scenario.
4 You can handle pagination. Custom apps allow you to define how to retrieve all data in the case pagination is implemented by the API. This ensures that users can easily get complete datasets without manually setting up repeaters and multiple calls in your scenarios. This also saves you credits!
5 You can implement more complex authentication methods. With custom apps, you can handle more complex authentication methods (like all the OAuth2 flows, token refresh mechanisms, or multi-step authentication) without needing multiple calls in your scenario. Saving credits, again!
6 You can implement complex calls. For tasks that require multiple calls and modules, custom apps let you combine them into a single API call. For example, if you need to retrieve data, create a new document, and add information from the first document, you can build a custom app to do all of this in one module.
7 You can create and personalize instant triggers. Custom apps allow you to personalize instant triggers by providing more control over webhooks. With a custom app, you can define the data structure in advance, so you don’t need to make a call to set it up. You can also define specific actions when a webhook connected to a third party API is created or removed. Additionally, custom apps let you create a webhook that can be shared across multiple scenarios, making it easier to reuse and maintain.
8 You can share your custom app with other users. Once you’ve built your custom app, you can make it available to users outside your organization, so they can use it without having to build it from scratch. Making their lives easier and making you the hero of the day.
Custom apps and APIs
To be able to build a custom app you just need an API (with some documentation to know how to use it). That’s it.
Different kind of APIs and services can be used when building custom apps:
REST API: The classic one.
GraphQL: Aiming to surpass REST API popularity. It provides a single endpoint and gives users more control over the data they request.
OData: An extension of REST APIs. It uses standardized query options and data handling features, simplifying tasks like filtering, sorting, and interacting with data. SOAP/XML: Older and more complex method for interacting with third-party services. More verbose and complex than REST APIs. It uses XML documents to carry all the call information.
RPC: The precursor of SOAP/XML. It uses larger XML or JSON documents.
Disclaimer: The list above contains protocols that allow access to third-party resources that utilize HTTP and its mechanisms (methods, headers, query parameters, body, etc), and because of this they are considered as APIs.
How to build a custom app?
You can build a custom app in Make in two ways: through the web interface within Make or by using Visual Studio Code.
Web interface
This option 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 course, you will use the web interface to build your custom app.
Visual Studio Code (VS Code) extension
This option lets you set up the custom app using the VS Code editor.
The extension is perfect if you prefer working in a developer-friendly environment. You work with local folders and files, using features like syntax highlighting, code formatting, integration with version control systems like Git, and collaborative development.
It connects to the Make API to retrieve your custom apps and sync the sources between your computer and Make, enabling offline work and easier file sharing.
However, because it requires access to the Make API, it is not available for Make Free accounts.
Check the documentation if you want to learn more.
App visibility
Your app can have different statuses that reflect its availability and ability to be used in the scenario editor.
Private
When you create a custom app, it is first set as private. This means only you, as the author, can see it in the scenario editor. You can use the app in your scenarios if you have the permissions to install apps in the organization (Owner, Admin, App Developer roles). However, other members of the organization won’t be able to use the app in their scenarios until you create at least one scenario with it.
Note that you must enable the modules to make them visible so that others in your organization can see and use them in their scenarios.
Published (approval not requested)
To share your app with people outside of your organization, you need to publish it by clicking the Publish button. Once published, you can share it with users from any organization using an invitation link. To install and use the app in the scenario builder, these users must have admin rights or permission to install apps (Owner, Admin, App Developer).
After publishing an app, it won’t be possible to: Change the app back to private
Delete the app
Remove any component of the app (e.g. a module)
Approved app (globally available)
To make your app available to all Make users in their scenario editor, you must request a review of the app. The Make team will verify that it meets Make’s conditions and best practices.
You can find more details about app visibility and the publishing process in the documentation.
APP VISIBILITY
Use case - HTTP call
In this course you will build a custom app to call the Geocodify API.
Geocodify converts addresses into geographic coordinates (latitude and longitude), making it easier to locate places on a map.
If you need to retrieve latitude and longitude for a specific address, Make doesn’t provide a built-in app for that. You have two options: either make an HTTP call using the HTTP app or build a custom app.
In this unit you will start by setting up the HTTP call focusing on the different elements
that you will use when building the custom app, which you’ll explore in the next unit.
The main elements to consider are:
Authentication
URL (base + endpoint)
HTTP method
Query parameters (if present)
Body (if present)
Headers
This is a simple and straightforward app that doesn’t require lots of work. However, it will help you understand the different elements and the advantages of setting up the call once, rather than having to repeat it every time you want to call the API.
Preparation - API token
Before you begin, you need to get the API token from the Geocodify API. On the Geocodify website, click Sign Up to create an account. Enter your details and click
Register or Login with Google.
After logging in, you need to retrieve the API key that you will use when setting up the HTTP call. Scroll down to find the API Token Information and copy your API Key.
API docs
To planthe HTTP call, start by studying the API documentation, where you will find the information on the different elements of the API call.
Authentication (1/3)
In this section you can find all the authentication details.
You can see that for this API you need to use an API key, which should be included in your request query string using the api_key parameter along with the value that you obtained from the Geocodify website.
API Base URL (2/3)
This section provides the base URL that you will use to access all the API endpoints.
API Endpoints (3/3)
This section lists all the available endpoints.
For this use case, you will use the /geocode endpoint to get the coordinates of a specific address.
Note that the documentation doesn’t specify the HTTP method, but since you are retrieving coordinates, you should use the GET method.
Query parameters
api_key: The API key used for authentication.
q: The address for which you want to retrieve the coordinates.
Postman test
It is good practice to test the HTTP call using Postman before building it in Make. This ensures that everything is working properly and helps you plan the HTTP call setup in Make.
In Postman, create a new request and add the necessary elements to make the HTTP call: Method: GET
URL (base + endpoint): https://api.geocodify.com/v2/geocode
Query parameters:
api_key: your API key
q: address you want to search, for example Champ de Mars, 5 Avenue Anatole France, 75007 Paris, France
Click Send. The API responds with a JSON file containing the address information and the API key.
If something is not working properly, use the error that the API returns to troubleshoot any issues.
HTTP call
If everything works fine in Postman, you can move on and build your call using one of the HTTP modules in Make. Use the information from the API documentation and the settings that you have used in Postman to set it up. The choice of which HTTP module to use depends on the authentication method required by the API.
For Geocodify, you need to provide an API key as a query parameter.
While you could make a generic request, the best option here is to use the HTTP> Make an API
Key Auth request module. This module lets you hide the API key, so it doesn’t appear in the scenario log and others can’t see it when editing your scenario.
Now, let’s set it up.
Note that the Make an API Key Auth request module allows you to create a new connection
that you can use when making other calls to the same API.
Click Start and work through each step. Set up the HTTP call
You can either follow along and build the HTTP call yourself, or simply have a look at all the steps needed to set up the call. Step 2
Step 1 - Authentication
In Make create a new scenario and add an HTTP> Make an API Key Auth request module. Click Create a keychain to insert your credentials. Click Add to insert your API Key.
You can rename the connection if you wish, then paste the API key you obtained from the Geocodify app in the Key field.
For API key placement select In the query string and type api_key as the parameter name, as specified by the API documentation.
Click Create to save your settings. Step 3
Step 2 - Module set up
Now, you need to add all the necessary information for the API call, including the address for which you want to retrieve the coordinates:
URL (base + endpoint): https://api.geocodify.com/v2/geocode
Method: GET
Query string: q=Champ de Mars, 5 Avenue Anatole France, 75007 Paris, France
Parse response = Yes (this allows you to map the response items if needed)
Click Save to save the settings. Step 4
Step 3 - Run
Save your scenario and click Run once.
After your scenario runs, open the output bundles and you will see that the API has returned quite a lot of information.
You will have to dig a bit and find the coordinates under Output> Data > Response > Features> 1> Geometry> Coordinates.
With custom apps, you can personalize the output bundle to retrieve this information more easily. Now that you’ve set up the HTTP call to call the Geocodify app, it’s time to create a custom app that has the same functionality. Move on to the next unit to begin exploring how to build a custom app.