V2 Actions silently fail and ignore scheme for http targets.

version: 4.1.2, 4.1.4
environment: self hosted

version: 4.1.2, 4.1.4
environment: self hosted

version: 4.1.2, 4.1.4
environment: self hosted

version: 4.1.2, 4.1.4
environment: self hosted

So when running Zitadel locally via docker compose for local development of my system/api, if I setup an action to post a request via webhook, rest call or async, they all silently fail if the target is for

http://localhost:8090/webhooks/zitadel.events

http://localhost:8090/webhooks/zitadel.events

http://localhost:8090/webhooks/zitadel.events

http://localhost:8090/webhooks/zitadel.events. I don't see any error logs when trying to trigger the calls to my api (i.e.

method: /zitadel.user.v2.UserService/CreateUser

method: /zitadel.user.v2.UserService/CreateUser

method: /zitadel.user.v2.UserService/CreateUser

method: /zitadel.user.v2.UserService/CreateUser via a

POST

POST

request to

{{ZITADEL_BASE_URL}}/v2/users/new

{{ZITADEL_BASE_URL}}/v2/users/new

{{ZITADEL_BASE_URL}}/v2/users/new

{{ZITADEL_BASE_URL}}/v2/users/new.

Is this a bug where the actions/triggers won't fire if the target endpoint is

http

http

http

http instead of

https

https

https

https?

I only figured it out by running an ngrok tunnel to my locally running api then pointing it to

{{ngrok_tunnel_url}}/webhooks/zitadel.events

{{ngrok_tunnel_url}}/webhooks/zitadel.events

{{ngrok_tunnel_url}}/webhooks/zitadel.events

{{ngrok_tunnel_url}}/webhooks/zitadel.events and receving the payload

Ask Inkeep•9/15/25, 4:46 AM

Hi @TheOriginalStove, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.

Ask Inkeep•9/15/25, 4:46 AM

Answer

I wasn't able to find a direct answer about HTTP vs HTTPS requirements for action targets in the available sources. The documentation shows examples using HTTP localhost endpoints for testing (1) (2) , but doesn't explicitly address whether ZITADEL blocks HTTP targets or if there are specific requirements.

Here are the most relevant sources for troubleshooting your action setup:

Test Actions Event : Shows how to set up a basic webhook target with HTTP localhost endpoint for testing actions with events.
Test Actions Request Signature Check : Provides guidance on implementing signature validation and troubleshooting action requests.

I'd suggest clicking the "Ask for help" button to tag a team member who can provide specific insight into HTTP target requirements and debugging silent failures in your version.

Ask Inkeep•9/15/25, 4:46 AM

To learn more, see the sources I considered:

[1] Test Actions Event
[2] Test Actions Request Signature Check

Ask Inkeep•9/15/25, 4:46 AM

Feel free to tag @Ask Inkeep with additional questions.

TheOriginalStoveOP•9/15/25, 5:01 AM

Also I noticed if you create a target in the console/UI the only way to get the signing key is by inspecting the page and grabbing it from the console.log output. Shouldn't it probably be displayed to the user so you can easily grab it?

I'd be more than happy to create a ticket and work on that as well.

Rajat•9/15/25, 10:58 AM

hey @TheOriginalStove thanks for your question, let me check it and I will get back to you

TheOriginalStoveOP•9/15/25, 2:37 PM

Thanks @Rajat

Rajat•9/15/25, 2:49 PM

hey @TheOriginalStove we recommend to use webhook.site instead of ngrok, we now have a guide on it too and I just tested that it works and no It’s not a code bug,this is by design. Actions needs the target endpoint to be HTTPS.
If you point an Action to plain http://…http://…, the trigger is ignored and you won’t see anything.

TheOriginalStoveOP•9/15/25, 3:09 PM

I'll take a look at webhook.site, but also not sure why it matters what tool I use to expose my local api for testing?

I feel like this should be configurable to target http when in development environments, similar to how you can set the redirect URIs to development mode.

At the very least it should be called out in documentation. I'm more than happy to help contribute this! Just need to finish launching my application this week lol

TheOriginalStoveOP•9/15/25, 3:18 PM

Also appreciate you looking into this @Rajat !

TTheOriginalStove I'll take a look at webhook.site, but also not sure why it matters what tool I u...

Rajat•9/15/25, 3:25 PM

you are right but outbound webhooks to arbitrary HTTP endpoints are a common abuse path, many platforms lock to HTTPS only,especially when redirects or browser-assisted flows are involved.
I have to check it with my team maybe we add a dev-only toggle to allow

http://

http://

Action targets on self-hosted instances (off by default), with clear warnings and scope limits.
if you have a better use case, feel free to open an issue around it

Rajat•9/15/25, 3:25 PM

and I will get it prioritised

TheOriginalStoveOP•9/15/25, 3:34 PM

I can’t think of any other use case except for local development with self hosted Zitadel to be honest.

TTheOriginalStove I can’t think of any other use case except for local development with self hoste...

Rajat•9/16/25, 11:03 AM

pls open an issue with your ideas and we'll see what we can do

koankem•11/9/25, 3:25 AM

@TheOriginalStove did you success with ngrok tunnel?

Kkoankem @TheOriginalStove did you success with ngrok tunnel?

TheOriginalStoveOP•11/9/25, 3:37 AM

Yes, ngrok also works to test locally.

koankem•11/12/25, 4:01 AM

hey @TheOriginalStove, do you use action for get information when a new user is created?

Kkoankem hey @TheOriginalStove, do you use action for get information when a new user is ...

TheOriginalStoveOP•11/18/25, 5:48 AM

I’ve been using the v2 actions that triggers on the events user.human.addeduser.human.added and user.human.selfregistereduser.human.selfregistered. I also listen for the method type /zitadel.user.v2.UserService/CreateUser/zitadel.user.v2.UserService/CreateUser.

Then in my API endpoint that’s the target for the webhook in Zitadel, I create the user in my system.

Kkoankem hey @TheOriginalStove, do you use action for get information when a new user is ...

TheOriginalStoveOP•11/18/25, 5:51 AM

Also sorry for the late response!