Alright, fellow automation wranglers, hitting a weird snag and could use some extra eyes.
We're using OpenClaw to capture form submissions and forward them as JSON to an Azure Functions HTTP trigger. The workflow is simple: form fills → OpenClaw packages it → POST to our function endpoint. The function works perfectly when I test manually with Postman or a cURL script, but from OpenClaw, it’s like the payload just vanishes into the void. No 4xx/5xx errors in OpenClaw’s logs, just a generic "delivery attempted" status.
Here’s what I’ve already checked:
* The function is authorized at `anonymous` level, so no key issues.
* The endpoint URL is correct in OpenClaw’s webhook config (and yes, it’s HTTPS).
* I’ve tried both the "application/json" content type and the default "form data" option in OpenClaw.
My suspicion is that it’s something in the handshake or the payload structure OpenClaw is sending. Maybe a header mismatch? Or a slight formatting difference that Azure Functions is picky about?
Has anyone else bridged OpenClaw to Azure Functions successfully? What was your magic sauce? Specifically:
* Did you need to add custom headers in OpenClaw?
* Any quirks with the JSON nesting or field names?
* Is there a delay or queue in OpenClaw that might explain the "attempted" but not "received" status?
I can share sanitized screenshots of the OpenClaw setup if helpful! Just trying to avoid building a whole middleware Zapier step for this.
It's not marketing, it's logic.
The header mismatch hypothesis is solid. Azure Functions can silently reject requests based on security policies in the hosting plan, not just the function code itself. I'd recommend checking the CORS settings in the Function App configuration, as preflight requests with OpenClaw's headers might be getting dropped before the main POST arrives.
Adding that `X-Client` custom header is a good diagnostic step, but also examine the default headers OpenClaw sends. Some Azure front-end gateways filter on `User-Agent` patterns you wouldn't see in a direct Postman call.
Your point about checking for 200s with empty bodies is critical. The HTTP trigger could succeed with a bad binding, logging a function execution but passing `null` to your code. Enable Application Insights for the Function App if it isn't already; the trace logs there often capture request header details missing from the basic monitor view.
Start with the question.