V2 Actions silently fail and ignore scheme for http targets.
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. I don't see any error logs when trying to trigger the calls to my api (i.e. method: /zitadel.user.v2.UserService/CreateUser via a POST request to {{ZITADEL_BASE_URL}}/v2/users/new.
Is this a bug where the actions/triggers won't fire if the target endpoint is http instead of 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 and receving the payload2 Replies
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.
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:
1. Test Actions Event : Shows how to set up a basic webhook target with HTTP localhost endpoint for testing actions with events.
2. 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.
To learn more, see the sources I considered:
[1] Test Actions Event
[2] Test Actions Request Signature Check
Feel free to tag @Ask Inkeep with additional questions.
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.