Not able to create an Asana Webhook to Okta Workflows

Workflows Questions
1

The Asana POST is expecting a 200 with the header key pair X-Hook-Secret: {value 1st card}. I’m using the Return Raw card, status = 200, and the header constructed from the API card headers. A simple test to the flow from VSCode,

POST https://arcinstitute.workflows.okta.com/api/flo/{Secure with client token}

Content-Type: application/json

x-hook-secret: test-secret-12345

The VSCode response shows x-azuqua-x-hook-secret: test-secret-12345

Could this be the problem with Asana not creating the webhook?

2

Hi @rcortez,

Could you share screenshots of how the request appears in Asana and of your flow?

3

Hi Max,

There’s nothing in Asana. I’m simply following the steps here, https://developers.asana.com/reference/createwebhook

Using my credential key and the target url as the Okta api.

This my okta workflow

image
image867×711 48.6 KB

4

Does the above flow work? Do you have another flow that registers the webhook?

The flow you shared looks correct.

When you register your webhook, Asana will send a request to the webhook (Workflows API endpoint), and you need to return the secret handshake via the X-Hook-Secret response header.

5

The flow does respond but it sends in the header x-azuqua-x-hook-secret:….., so Asana fails to create the webhook. Make.com successfully creates an Asana webhook to a make.com scenario. This app correctly responded with “x-hook-secret”: in the header. It looks like the raw response card appends x-azuqua-

Here’s the full response using the flow and the VScode describe at the start of this.

HTTP/1.1 200 OK
Date: Tue, 24 Feb 2026 22:05:06 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: close
surrogate-control: no-store
cache-control: no-store, no-cache, must-revalidate, proxy-revalidate
expires: 0
access-control-allow-origin: *
access-control-allow-headers: Origin,X-Requested-With,Content-Type,Accept
content-security-policy: default-src ‘self’;script-src ‘self’ ‘unsafe-inline’;style-src ‘self’ ‘unsafe-inline’;font-src ‘self’;upgrade-insecure-requests;report-uri /api/system/report-csp
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
x-download-options: noopen
x-xss-protection: 0
x-azuqua-trace-id: 6e9a291b-c0a8-410d-ad4f-4d1c4c628e64
x-azuqua-span-id: 6e9a291b-c0a8-410d-ad4f-4d1c4c628e64
access-control-expose-headers: x-flo-instance
x-flo-instance: 1eaeb276-3815-425a-9ba5-8a68bfa4d5dc
x-azuqua-x-hook-secret: test-secret-12345
x-flo-execution: 1eaeb276-3815-425a-9ba5-8a68bfa4d5dc
etag: W/“0-2jmj7l5rSw0yVb/vlWAYkK/YBwk”
x-envoy-upstream-service-time: 251
server: istio-envoy

Sorry for not being very clear at the start of this thread.

Thanks

6

I reproduced the same issue. Workflows modifies the response header and sends back x-azuqua-x-hook-secret. It’s a bug. To prioritize this bug, can you create a support case? Could you also DM me the case number? You can also email it to me (max.katz@okta.com).