FYeah the UX of the actions are not great.
This is one of the reasons why actions v2 are working differently. You basically get the data from zitadel and then can work them in your own runtime (even locally). So close to a webhook
This is one of the reasons why actions v2 are working differently. You basically get the data from zitadel and then can work them in your own runtime (even locally). So close to a webhook
FSome docs for the v2 action https://zitadel.com/docs/concepts/features/actions_v2
By using ZITADEL actions V2, you can manipulate ZITADELs behavior on specific API calls, events or functions.
SOnly concern I've been worried about is the order of magnitude latency cost over actions v1, local js style execution in the go runtime adjacent to zitadel vs reaching out over HTTP/gRPC to <somewhere> on the internet and back - for complement token workloads it might add a decent amount of latency.
SYeah they are, an I imagine (hope) the ui will have the ability to list all the action v2 hooks and allow you to send mocked events of various types to the endpoint so you can debug/develop quickly against payloads.