How to Specify a Raw Body on a Custom Connector instead of JSON?

[ErickDiaz]

Hi,

I’m creating a Flow process that uses a custom connector to access an on-prem API using the data gateway. I’m on the first step process to get the access token, the POST method expects a raw body as follow:

grant_type=password&username=myusername123&password=mypassword123&scope=api

Unfortunately, the custom connector only allows me to define the body in a JSON format so my connector is failing because of the body:

{
"grant_type" : "password",
"username" : "myusername123",
"password" : "mypassword123",
"scope" : "api"
}

When testing the custom connector, there is an option that let’s me specify a raw body and the test is successful.

Custom Connector - JSON Body Failed 400:

Custom Connector - Raw Body Succeeded 200:

However, when I create my flow, I do not have the option to pass the body as raw:

Any idea how to pass a raw body to my custom connector?

Thank you,

Erick

[maneesh]

@HEATFreight I am literally in the same boat as you are.

Canvas app just won't pass body to the custom connector no matter what.

Sigh! Did you find it to work?

[HEATFreight]

@maneesh  Well, no I did not get the custom connector working with the API I was having trouble with, but I've made huge progress and I did get a custom connector working perfectly with the QuickBooks Online API.

First, I'll say that custom connectors are janky. There are bugs. I prefer using the Swagger Editor that's built into the custom connector interface. I refuse to use the basic custom connector editor interface because it causes things to break which would otherwise work with the Swagger Editor. I import a Postman v2.1 collection to build the custom connector. I save from the >Security tab after inputting all the OAuth2 credentials and before moving on to the >Definition tab. And in the >Definition tab I make no changes at all except while the Swagger Editor toggled on.

Here is the guide I followed
^^the above link is broken, here's a wayback link


The biggest lesson learned is that you should probably be using OAuth2 in the Postman >Authorization tab, assuming the API you're using works with OAuth2. My first attempt at building a custom connector was for a 3rd party API, call it Example.com, which allows both the password grant type and the auth code grant type. The password grant type is simpler for an API novice to work with, but I don't think there is any easy way to make the password grant type authorization flow work within the custom connector. So that was the crux of my issues on the first attempt. I was probably doing it wrong, so I'm not sure that the empty request body parameter issue was really the root of the problem.

The secret is OAuth2 works automatically in the background of the custom connector. If you do it right, you do not have to hard code any authorization/authentication/refresh requests manually. In Postman, you will need to manually build a separate request outside of your collection to refresh your access token, since Postman has no functionality to keep it refreshed automatically. Put the important bit is, if you want to try this OAuth2 thing, you don't need to import any auth/refresh requests into the custom connector. Custom connectors make those requests for you in the background. There is something called the "OAuth2 authorization code flow" which consists of at least one GET request and two POST requests, followed later by another POST request once access token has expired. The GET-POST-POST sequence basically redirects user to a login page for the API, where they input username and password, then it returns an authorization code which is used to request an access token. Along with the access token, you of course get a refresh token and expiration time.

So whenever you click "New connection" in the >Test tab of custom connector, or if your user tries to run the Power App and is prompted to create their own connection, the custom connector automatically runs that sequence of requests called the auth code flow. So you automatically get redirected to the login page, and submitting the login credentials automatically produces your tokens, and the custom connector automatically parses the response body to store those token properties for later use, and finally once the access token expires the custom connector automatically refreshes the token. I used to think I would have to manually build the GET-POST-POST sequence for the auth code flow, as well as the later POST request that keeps the token refreshed. But that's not true. DO NOT MANUALLY BUILD THESE REQUESTS. Postman does them for you and the custom connector will as well. If you do try to replicate those request manually, do so in a separate collection from the one you plan to import into the custom connector. You will need to manually build the refresh token request in Postman if you want to keep the token refreshed while testing in Postman, but keep it separate from the collection you plan to export. The collection you will export should be just the normal API requests, like POST Invoice-Create or GET Customer-ReadByID (to borrow examples from the QuickBooks Online API). Each of those requests should have OAuth2 authorization option (Postman's inherit auth from parent option won't work when you export the Postman collection and import to custom connector, so each request has to have that OAuth2 setting set explicitly). Most of the rest of the OAuth2 settings in Postman will not import to the custom connector, so you will have to reenter those values in the >Security tab of the custom connector (like client ID, client secret, token URL, refresh URL, and scope).

Anyway, so I was able to get the QuickBooks Online API working perfectly, and it keeps itself refreshed. Access token expires after one hour, but my QuickBooks Online API custom connector has stayed connected for a few weeks now and is still going strong. I can't say the same for that "Example.com" API. Now that I've successfully got the QBO API working in a custom connector, I thought "why not try to replicate this with the API that was giving me trouble before?"

Well that "Example.com" API (not really example.com...) seems to be breaking the custom connector due to a triple-slash-escaped JSON-formatted string included in an extra response property of that API. The QBO API does not have anything like that in its response, and it works perfectly. "Example.com" works perfectly as a custom connector for 20 minutes, then the access token expires and it fails to refresh. I think it fails because Swagger Editor regards triple-backslash as a comment line, so I believe that custom response property in the "Example.com" API is breaking the custom connector. Microsoft support ticket still open with no resolution. So, I've abandoned "Example.com" as a custom connector for now. It's just not compatible. I have it deployed using the resource owner password grant type in a series of Power Automate flows. It's clunkier and more difficult to build, use, debug, and edit than a custom connector, and probably has higher latency, but it works.

Moral of the story is: if you're still stuck on passing in an empty request body property to the custom connector from Power Apps, you may have a similar situation as me. You may benefit from using the OAuth2 auth code flow to have custom connector automate the token generation and refresh process for you.

Now technically I don't think I've tested a fully functional custom connector with an empty request body from Power Apps again yet, so all of this may be totally irrelevant to the issue you are having.

Suffice it to say that, when custom connectors work, they work beautifully and are really, really, really easy to configure. Like, if it's not working for you, it could be some incompatibility like what I encountered with "Example.com" API. For me, following that guide I linked to above made the QBO API mind-blowingly simple to deploy in a custom connector. Try following that QBO guide for the API you're working with, or if you have a QuickBooks Online account, try building a QBO API custom connector. If you can get that working, it will be a lot easier to understand what's going on with your other API. For me it made all the difference. I wasn't successful at deploying "Example.com" in a custom connector, but I did find a bug that has stumped the Microsoft product managers. I wouldn't have understood everything at the level I do now had I not found that QBO custom connector guide.

Here is a thread where I go into great depth about the two APIs I'm working with, one that works gre...


Edit: Wow, typing out this response made me consider doing something I haven't tried yet: OAuth2 Authorization type with grant type set to "password credentials". I have successfully manually built the auth request for the password grant type, and I have tried importing the manually built authorization and refresh requests for that password grant type into the custom connector (doesn't work at all), but I have not tried using the OAuth2 settings to get the custom connector to run the auth/refresh requests for me, without me having to manually build them in the collection. Oh but I just realized that won't work because the triple-backslash escape character from the "Example.com" API response body property will still cause the same bug that prevents the custom connector from parsing the response body and storing the refresh token, so no matter which grant type I use, the custom connector will fail to refresh the token for this particular API. My Power Automate solution works fine for now, so will stick with that until a better solution presents itself...

[Ganeshkumar08]

Facing a similar issue, Do we have any workaround for this? In my case, I have created a custom connector but by default it is hitting with an empty json body like '{}' but I have to pass the raw body as empty then only the API will work!