Power Platform Community Forum Thread Details

I am trying to get a webhook/callback action to work from ValidSign to Power Automate.

The callback works from ValidSign's endpoint, as when testing with a test URL it is correctly received, but when I use Power Automate's URL (generated either with the HTTP received action or the webhook action, the webhook action successfully modifies the callback event on ValidSign's side) it does not work. The flow isn't even triggered, so I can only assume it is blocked by Power Automate as a whole. When I manually send a request through e.g. curl with the same info the flow triggers normally. I also tried changing the generated URL's encoded characters (%2f to /), but that also didn't work. The only relevant thing I could find is that ValidSign recently changed their IPs: https://kb.validsign.eu/en/getting-started/wijziging-in-de-ip-adressen-van-de-validsign-omgeving

Categories:

Using connectors

Using flows

Hi @MG-29050750-0,

What you’re describing is a classic case where the webhook provider (ValidSign) can reach generic endpoints but Power Automate’s HTTP Request trigger is not firing because of how Microsoft protects those endpoints.

Here are the key points to check:

🔎 Common causes

IP whitelisting: Power Automate endpoints are behind Azure infrastructure. If ValidSign recently changed IPs, those new ranges may not be allowed through Microsoft’s firewall. Curl works because you’re sending from a public client, but ValidSign’s servers may be blocked.
👉 You’ll need to confirm whether Microsoft requires you to whitelist ValidSign’s IPs. ValidSign’s KB article shows their new IP ranges — you may need to raise a support ticket with Microsoft to allow those ranges.
Trigger type mismatch:
- The “When an HTTP request is received” trigger expects a POST with a body matching the schema you defined. If ValidSign sends headers or formats differently, the flow won’t trigger.
- The “Webhook” trigger requires a proper subscription handshake (validation response). If ValidSign doesn’t support that handshake, the subscription may appear successful but events never arrive.
URL encoding: You already tested %2f vs /. Power Automate URLs are case‑sensitive and must remain exactly as generated. Any alteration breaks routing.
TLS / certificate issues: ValidSign must support TLS 1.2+ and trust Microsoft’s certificates. If their outbound system rejects the SSL handshake, the request never reaches your flow.

✅ Steps to troubleshoot

Check ValidSign logs: Do they show a 200/202 response from Power Automate, or a connection failure? If it’s failing before reaching Microsoft, it’s an IP/network issue.
Test with a proxy: Point ValidSign’s callback to a service like Webhook.site or your own Azure Function. If that works, the issue is specifically with Power Automate’s endpoint.
Confirm trigger type: If you’re using “When an HTTP request is received,” make sure the schema matches exactly what ValidSign sends. Try removing the schema temporarily to see if the flow triggers.
Raise with Microsoft support: Provide them with ValidSign’s new IP ranges and ask if those need to be whitelisted for inbound requests to your tenant.

🚀 Practical workaround

If you need this working quickly, you can:

Point ValidSign’s webhook to an Azure Function / Logic App that accepts any request.
From there, forward the payload into Power Automate using the HTTP action.
This avoids the IP restriction issue and gives you full control over request validation.