Make API: Creation and Validation/Testing of Make Connections via Make API (with solution!)

[zezutom]

Hi,
I would like to get some clarity on the use of the Create Connection endpoint. I created a new connection as outlined here: https://www.make.com/en/api-documentation/connections-post

Now, there are several issues:

Issue 1: The newly created connection is not listed
I cannot see it neither in the Connections tab in my organisation, nor is it listed when I call https://www.make.com/en/api-documentation/connections-get

However, I can get the connection’s detail, which brings me to the next problem.

Issue 2: OAuth fields are empty
When I obtain the connection’s detail by calling https://www.make.com/en/api-documentation/connections-connectionId-get, then the scopeCount is 0 and the scopes array is empty. Also, there is no clientId or clientSecret.

To make it clear, if I create a new connection like this:

curl -X POST \
'https://eu1.make.com/api/v2/connections?teamId=1' \ 
-H 'Authorization: Token abcdefab-1234-5678-abcd-112233445566' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{"accountName":"Slack Test","accountType":"slack","clientId":123456,"clientSecret":"secret","scopes":["chat:write"]}'

The call is successful and it immediately returns this response:

{
   "connection":{
      "id":764265,
      "name":"Slack Test",
      "accountName":"slack",
      "accountLabel":"Slack",
      "packageName":null,
      "expire":null,
      "metadata":null,
      "teamId":1,
      "theme":"#4a154b",
      "upgradeable":false,
      "scopes":0,
      "scoped":true,
      "accountType":"oauth",
      "editable":false,
      "uid":null
   }
}

As you can see the defined scopes, clientId and clientSecret are lost.

When I obtain the connection details by calling:

curl -X GET 'https://eu1.make.com/api/v2/connections/764265' -H 'Authorization: Token abcdefab-1234-5678-abcd-112233445566'

I get:

{
   "connection":{
      "id":764265,
      "name":"Slack Test",
      "accountName":"slack",
      "accountLabel":"Slack",
      "packageName":null,
      "expire":null,
      "metadata":null,
      "teamId":55228,
      "theme":"#4a154b",
      "upgradeable":false,
      "scopesCnt":0,
      "scoped":true,
      "accountType":"oauth",
      "editable":false,
      "uid":null,
      "scopes":[
         
      ]
   }
}

Can someone pls clarify the correct use the Create connection endpoint? Thank you.

[ahmet.tas]

@zezutom

omeone pls clarify the correct use the Create connection

Hitting exactly the same problem. See no chance to programmatically create connections via Make API.

If there’s and endpoint why it doesn’t return an expected result? This makes no sense and is clearly a bug

[zezutom]

Yeah, there are more endpoints that don’t work as documented. But this one is crucial. I am writing a client in Go and have plans to create a Terraform provider. So that connections and other components which present a potential security risk can be managed by code. However, without the API working properly I am stuck and cannot help on this front.

[ahmet.tas]

My usecase is a bit different. I’m duplicating my blueprint scenario for customers after purchase and want to provide them with a “no touch” installation.

So they enter credentials to an make app somewhere else on my website and these credentials (user+pw) should be used inside this duplicated scenario.

[PierreL]

@Tiwa_Shada @Iveta_Sofkova

[Darin_Patterson]

Hi everyone , I have some experience in this topic that I can certainly share.

1. There is a big difference between creating Oauth connections and non-Oauth connections. Non-oauth connections are relatively straightforward and this post might help with that.

2. The most important part of Oauth connections (like Google-drive) is that, based upon the core principles of Oauth, the user is required to do something (grant access within the 3rd party application) during the process. In other words: most oauth protocols (there are a few) require a user to be involved in the granting process (e.g. the user goes to Google and says “yes, I would like for Make to have access to my Google stuff”). There are some benefits of this from a security standpoint, (as in the accessing solution, like Make, doesn’t actually know your password, etc. and the 3rd party solution is always in charge of access).

3. Given that big caveat, here’s the way you can work with the Make connections API to create an Oauth connection.

Steps

1. Create the connection with the following endpoint as you have already determined.

Create new connection
POST /v2/connections

Required scopes: connections:write

Query Parameters

• teamId [integer] the unique ID of the team in which the connection will be created

Request Body

• accountType [string] The unique name of the connection type that is associated with the application
  – Example: google-restricted, jira

• accountName [string] The name of the connection that is used to differentiate this connection from others
  – Example: My Google Connection

• {{other fields}} [various] Any other “name” fields from the get connection information request and their corresponding values. (e…g url, username, etc.). The vast majority of Oauth connections don’t have any other fields…but non-Oauth connections would (e.g. apiKey, etc.). See this post here for more information.

2. At this point (as you noted) the connection isn’t really in Make yet (Make only accepts valid connections). So you have to perform the OAuth authorization. To do that, you can, first determine the URL to send the user to.

Get the redirect URL for user to perform authorization in 3rd party service
GET /v2/oauth/auth/{connectionID}

Required scopes: connections:write

Path Parameters

• connectionID [integer] The unique ID of the connection for which authorization should occur (obtained from previous step)

• scope [string] The scopes that need to exist in Make for this connection. Tip: Look at a connection created in Make already and view the scopes there.

Important: the format of requesting multiple scopes needs to be non-serialized in the URL and in the same order as the scopes listed in Make. Example: &scope=chat:write&scope=chat:write.public&scope=chat:write.customize&scope=channels:read&scope=groups:read&scope=im:read&scope=mpim:read&scope=users:read

This endpoint will return with a 302 (an automatic redirect) that will take you to Make and then the 3rd party service. Note: if you are calling this endpoint with a Make module – it will automatically redirect to that place which is not what you want. You’d want use an HTTP call to determine where the redirect should go to …then present that to your client in whatever way works for you.

At this point, the user needs to actually do the authorization in the 3rd party service (e.g. Google). They will be requested to authorize Make and complete the process. At which point, Google will send Make an authorization code (that Make can use to get the access token).

3. The last step is to “verify” the connection by calling the following endpoint (basically ensuring that all of the other steps have been completed).

Test the newly created connection
POST /v2/connections/{connectionId}/test

Required scopes: connections:write

Path Parameters

• connectionID [integer] The unique ID of the connection to be validated (obtained from previous steps)

Response Example

{
"verified": true
}

I know all of that is a lot and yes, I know Make will update official documentation on this topic. But hopefully, that is all helpful.

[Albanmana02]

Hey Darin,

Thank you so much for this valuable post. This is something that I’ve been wanting to do for months now.

I still encounter some bugs with your method, while trying to create a connection for Slack :

• 1. The GET /v2/oauth/auth/{connectionID} doesn’t return a 302 like you said, but a 200 with an HTML response. The response contains an encoded url that does redirect to the OAuth page.

However, if you replace the GET with a POST request (POST /v2/oauth/auth/{connectionID}), you get a different response with an URL containing a token. This url also redirects to the OAuth page.

Not really a bug so far, but I don’t get the 302 response, is that an issue ?

• 2. The scopes appear, but don’t work

You said in your post to use the “scope” query parameter to request scopes to the selected app.

However after I finish the Authorization and Test the connection, I get a single “scope” in the connection, with all of the scopes I requested still separated by commas.

Basically you can put whatever you want in the “scope” parameter, and it will appear as a scope in the connection, but you can’t do anything with it and it doesn’t grant any permission.

I asked ChatGPT for help and it said that the issue is likely to come from how the /v2/oauth/auth/{connectionID} endpoint and subsequent internal API calls handle the “scope” parameter.

Would you have a solution to that ? I even tried to use the key “user_scope”, since it’s what is present in the Slack url when you try to create a connection manually, but it doesn’t work either.

Again thank you for your help, some of us have been looking for a solution to this for weeks, months or years, and I feel like we’re 95% of the way there.

[Darin_Patterson]

@Albanmana02

Not really a bug so far, but I don’t get the 302 response, is that an issue ?

Hi Alban, regarding #1 (getting the oauth redirect URL) – there is an advanced setting in Make’s HTTP module which automatically follows redirects. If you change that to “no”, then it will return the redirect URL, rather than trying to go there. See screenshot.

[Darin_Patterson]

@Albanmana02

You said in your post to use the “scope” query parameter to request scopes to the selected app.

You are right – I was missing an important part of the directions here. I’ve updated the post. But essentially the answer is to make sure the format of the request parameters is repeating and non-serialized.

*Example: *
scope=chat:write&scope=chat:write.public&scope=chat:write.customize&scope=channels:read&scope=groups:read&scope=im:read&scope=mpim:read&scope=users:read