reliable way to know if user just got created
I'm integrating analytics and in my OAuth callback and I want to track the user login event.
I do need to know in detail if it's a login in or a signup event. By login I mean "has the user already logged in in any application before now". That applies for password signin/signup as well as IDP automatic registration
I see nothing in the accessToken that would give me that information.
The current solution I envision is
- call FA and retrieve the full user
- Loop on all user.registrations to extract the minimum
- check if that
insertInstantis less than X second (let's say 15) before current time
Is there a better (faster ? more reliable ? ) way to get that information?
dan last edited by
Have you tried webhooks? https://fusionauth.io/docs/v1/tech/events-webhooks/events
You can see a successful login. You can also see user creation. I haven't implemented this myself, but from reading the code I believe this event fires on both IdP and traditional logins, and you can distinguish between these using the
authenticationTypeattribute. I don't see a way to distinguish the login when someone registers vs when someone signs in, but if that is important you could file a github issue.
Now, I'm not sure if you're trying to add this into an existing system or a new one.
If it was a new FusionAuth system, I'd set up two webhook listeners. I'd have one that listened to the user create event and added a row to a table (
first_login_instantcolumns). Then if I saw a login event, I'd see if that user had signed in before. If not, it was a signup, otherwise it is a login. Then add the
If it is an existing FusionAuth system, I'd populate the
user_signup_analyticstable first based on the login records ( https://fusionauth.io/docs/v1/tech/apis/login#export-login-records ) unless you'd deleted them.
"has the user already logged in in any application before now"
This means you can't use the registration created webhook, because that is fired on a per application registration basis.
Because this is user info, you may want to consider listening to the user delete webhook so you can remove their row from the
user_signup_analyticstable if they want to be deleted as well.
If webhooks don't work for you, I could see some kind of polling process that would do what you lay out, but stores the data somewhere (perhaps in
user.data) as a cache. Not clear to me what your performance requirements are, though. Perhaps searching in elasticsearch to find users created since the last time the polling solution ran? But webhooks feel cleaner to me.
Have you tried webhooks?
Nope, webhooks completely slipped my mind, that's actually even better or my use case
Thanks for the detailed answer!