Power Platform Community Forum Thread Details

Description:

I am experiencing a persistent 401 Unauthorized error when calling the Productboard "Notes" API via a Custom Connector, despite the same configuration working perfectly in Postman.

Troubleshooting Completed:

Token Validation: Confirmed via Postman that the OAuth 2.0 Access Token is valid, has the notes:read scope, and belongs to the correct user/workspace.
Header Verification: The request includes mandatory headers: X-Version: 1, Accept: application/json, and Authorization: Bearer [token].
Outbound Request Inspection: I changed the Connector Host to Webhook.site to inspect the raw outbound request from the Power Platform Gateway.
- The Result: The Authorization header correctly contained the Productboard Bearer token.
- The Observation: The Power Platform is successfully passing the token, but Productboard is rejecting the request with a 401 when the host is set back to api.productboard.com.
Security Layer Test: Attempted to "mask" the request by adding a User-Agent: PostmanRuntime/7.41.1 header. This resulted in a 403 Forbidden (likely a Cloudflare JA3 fingerprint mismatch).
Direct Node Test: Calling the connector directly from a Copilot Studio Agent node also results in a 401.

The Technical Conflict:

Since the token is confirmed valid (via Postman) and is confirmed to be sent by the Gateway (via Webhook.site), why would the destination API return a 401 only when the request originates from the Power Platform?

I suspect there is a hidden header or a "Traffic Fingerprint" (User-Agent, etc.) being injected by the Azure API Hub / Island Gateway that is causing Productboard's security layer (Cloudflare) to drop the authentication context.

The Ask:

Is there a known issue where the Authorization header is stripped or modified by the Gateway when talking to specific external APIs?
How can I ensure the Power Platform sends a "clean" request that matches the fingerprint of a standard tool like Postman?
Is there a way to view the actual response headers from the 401 error (the ones from Productboard, not the Microsoft proxy) within the Power Platform?

Categories:

Building Power Apps

Connector development

HI @AD-16021546-0,

In the first place, I would suggest contacting the API provider if they have known restrictions on requests from Power Platform or require whitelisting.

The Ask Vs The Ans:

Answer to the question no 1:

Basically, when using an on-premises data gateway or certain network configurations, the Power Platform Gateway or proxy layers can strip or modify headers like Authorization. This type of case may arise due to security policies, restrictions in header, or gateway limitations. Usually in custom connectors, if we manually add an Authorization header while OAuth is configured, the platform may override or ignore it, causing issues. Hence, it’s very important to configure OAuth properly in the connector’s security tab and avoid manually setting Authorization headers in the request.

Answer to the question no 2:

At this point, I can say there is a chance Power Platform’s HTTP requests may differ from Postman in TLS fingerprints, User-Agent headers, or other subtle network characteristics. To put check on this what we can do:

Please avoid manually setting User-Agent headers that kind of same in Postman, as this can trigger security blocks (e.g., Cloudflare JA3 fingerprint mismatches).
I would suggest using Power Automate’s default HTTP actions or Custom Connector OAuth flows without overriding headers – this is very important.
One additional area to ensure your connector’s host, base URL, and request format exactly match Postman’s working requests.
It’s always better to test requests via Webhook.site or similar tools to compare raw requests, check the details there.

Answer to the question no 3:

It is a very sensitive area, as we know Power Platform’s built-in HTTP actions and Custom Connectors do not directly expose full raw response headers in the flow run history. What we can do alternatively is:

Use the Custom Connector’s Test tab to see detailed request and response info, including some headers.
Add logging or proxy tools (like Webhook.site) to capture outbound requests and responses.
One additional option to use Azure API Management or other API gateways as intermediaries to log full headers.
In HTTP actions, capture the response body and status code, but headers are limited.
To do some advanced diagnostics, we can use Fiddler or network tracing tools on your client or gateway environment.

Lastly, please capture response body and status code in flows for error handling, though headers remain limited.

Before I close, take a separate flow, test only HTTP connector to see how it behaves.

Please let me know if these area help to resolve the issue.

I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!