Fyes that is right, as the actions are implemented into the flows of the ui of zitadel. we assume that most of the things you want to achieve in your ui, you can directly implement yourself
Fhowever we will also have a look at how we can make the actions available again for the session API/new login, it might not possible to migrate everything as it depends on where it is needed. (backend or frontend)
Fin case of frontend it would be up to you to also implement them in your ui
SI have a few blockers as zitadel actions are not working with Custom login UI in onboarding user flows on our application.
User Creation Information: I need to add the user's creation date in the user info at the time of account creation. What's the best approach to update user info during creation, either through the frontend or backend?. I want to implement an in-app guide for new users during their first session or first hour of their initial login.
Welcome Email Process: I need guidance on handling welcome emails for different authentication scenarios:
For email/password flow, I can trigger the welcome email as I know when the user is created.
For IDP logins (like "Login with Google"), first-time users can bypass the registration process, making it difficult to identify when to send the welcome email.
API Usage Optimization: If Actions aren't functioning, we'll need to make additional requests from the frontend/backend, increasing our API usage. How can we minimize API calls in scenarios requiring authorization, grants, etc., as our dependency on Actions might increase in the coming days? Is there any plan to extend it for custom ui login as well.
User Creation Information: I need to add the user's creation date in the user info at the time of account creation. What's the best approach to update user info during creation, either through the frontend or backend?. I want to implement an in-app guide for new users during their first session or first hour of their initial login.
Welcome Email Process: I need guidance on handling welcome emails for different authentication scenarios:
For email/password flow, I can trigger the welcome email as I know when the user is created.
For IDP logins (like "Login with Google"), first-time users can bypass the registration process, making it difficult to identify when to send the welcome email.
API Usage Optimization: If Actions aren't functioning, we'll need to make additional requests from the frontend/backend, increasing our API usage. How can we minimize API calls in scenarios requiring authorization, grants, etc., as our dependency on Actions might increase in the coming days? Is there any plan to extend it for custom ui login as well.
Sany update?
FHey there
Let me try and give some pointers here.
The Users Api (in the v2 api) allows you to set metadata directly https://zitadel.com/docs/apis/resources/user_service_v2/user-service-add-human-user that should be usable here.
I see these options here.
1) you can trigger a mail sending out of the "login code" you have
2) actions v2 should soon also have events that you can use to trigger your services (like we send you an event after the user registered) -> I think this in review as we speak https://github.com/zitadel/zitadel/pull/9249
I am not sure I understand this fully, but given you build your own UI you can control already how many calls you make to our API.
Actions will be more and more extended to cover cases that the hosted-login had over time. There is an Epic to track that here https://github.com/zitadel/zitadel/issues/7235
Let me try and give some pointers here.
User Creation Information: I need to add the user's creation date in the user info at the time of account creation. What's the best approach to update user info during creation, either through the frontend or backend?. I want to implement an in-app guide for new users during their first session or first hour of their initial login.
The Users Api (in the v2 api) allows you to set metadata directly https://zitadel.com/docs/apis/resources/user_service_v2/user-service-add-human-user that should be usable here.
For IDP logins (like "Login with Google"), first-time users can bypass the registration process, making it difficult to identify when to send the welcome email.
I see these options here.
1) you can trigger a mail sending out of the "login code" you have
2) actions v2 should soon also have events that you can use to trigger your services (like we send you an event after the user registered) -> I think this in review as we speak https://github.com/zitadel/zitadel/pull/9249
API Usage Optimization: If Actions aren't functioning, we'll need to make additional requests from the frontend/backend, increasing our API usage. How can we minimize API calls in scenarios requiring authorization, grants, etc., as our dependency on Actions might increase in the coming days? Is there any plan to extend it for custom ui login as well.
I am not sure I understand this fully, but given you build your own UI you can control already how many calls you make to our API.
Actions will be more and more extended to cover cases that the hosted-login had over time. There is an Epic to track that here https://github.com/zitadel/zitadel/issues/7235
SThanks for the reply. Usage of metadata is worked for storing creation date.
Here, I want to trigger a welcome email. I am not sure how to differentiate on the IDP login flow if someone tries to log in as a first-time user (on login user will be created) without using the registration flow.
I assumed that usage of action triggers, for example, to update metadata, grants, authorisations, etc will not impact api limit. But if I do the same using api call, then it will be counted. Let me know if this how it works or not.
you can trigger a mail sending out of the "login code" you have
Here, I want to trigger a welcome email. I am not sure how to differentiate on the IDP login flow if someone tries to log in as a first-time user (on login user will be created) without using the registration flow.
I am not sure I understand this fully, but given you build your own UI you can control already how many calls you make to our API.
I assumed that usage of action triggers, for example, to update metadata, grants, authorisations, etc will not impact api limit. But if I do the same using api call, then it will be counted. Let me know if this how it works or not.
JHi @fabienne @Matías @ffo , We’re experiencing issues using Actions V2 with a custom UI. We're triggering:
Is there any update or workaround to make this work? Your help would be greatly appreciated.
- A
REST Call Targetwith aFunction Action Trigger - A
REST Webhookwith anEvent Action Trigger
Is there any update or workaround to make this work? Your help would be greatly appreciated.
MHey @JoseSzycho, can you tell me the Zitadel version your instance is running? Also, are you self-hosting or using Zitadel cloud?
Jhey @Matías , we are using Zitadel v3.3.0, the self-hosting version
MGot it. I will test this myself and get back to you shortly with my findings.
JThanks @Matías We're looking forward to hear from you
MHi @JoseSzycho, sorry about the late reply, I had to deploy a fresh version of my custom login for testing and create an endpoint in my backend for the action target, etc. Anyway, I just tried adding an Event Action trigger and tested the sign up flow, is that one of the flow you were testing? You mentioned that you were trying to capture the event
I just printed all the events that were triggered during the signup flow, and this is what I got:
I believe it's safe to say that the relevant one is
user.human.selfregistered, right? Since the custom login UI uses the sessions API and works slightly different from the hosted one, you might need to check a different event. I just printed all the events that were triggered during the signup flow, and this is what I got:
user.human.addedsession.addeduser.human.password.check.succeededsession.user.checkedsession.password.checkedsession.lifetime.setsession.token.setauth_request.session.linkedauth_request.code.addedauth_request.code.exchangedoidc_session.addedoidc_session.access_token.addeduser.token.v2.addedauth_request.succeededI believe it's safe to say that the relevant one is
user.human.added. As you see, it no longer triggers the user.human.selfregistered event.MI will test the other triggers for a user login (function/preuserinfo and function/preaccesstoken) and let you know what I receive in my target endpoint
MHey @JoseSzycho, I just tested function/preuserinfo and function/preaccesstoken and it works for me. I'm using Zitadel cloud for testing, it's on version 3.3.2, and I forked and deployed the custom login today, so it's also the most recent version.
JHey @Matías Thank you for the update and for the effort in your testing. Seems that we were trying to use the wrong triggers then. Really appreciate your work. We're going to give it a try.
As for the
As for the
Function Action Triggers , are they working on the custom-ui?M@JoseSzycho yes, I sent you a screenshot from the app I was using for testing, and the json payloads I received via DM. I tested it with a React app, using a custom login UI. I'm using Zitadel cloud on v3.3.2 for testing. Both function action triggers worked for me
JThank you very much @Matías ! We're going to give it another try
MPlease let me know how that goes!