Yes, you would need something on your end to poll the Audit Log to fetch changes made to the Entities. Currently. there's no way to enter a log into the system logs (fusionauth-app.log) or otherwise control what goes in there. We do have a similar example for Cloudwatch on exporting Login Records to Cloudwatch which should be helpful.

https://fusionauth.io/docs/operate/monitor/cloudwatch

This is a little tricky since a user could log in from either provider at any given time. The JWT populate lambda only has access to the user object and the registration object so you would need something on either of those to reference in the lambda. Each time a user logs in from a Identity Provider, the user in FusionAuth gets updated with the user data from the IdP. So for the JWT populate to work, you would need both providers to have a custom data field that maps to the same user.data field in FusionAuth. Then have the JWT populate Lambda map this user.data to either a custom claim or to the roles claim in the JWT, whatever works to determine the internal role on your side. Essentially this field would get updated or overwritten every time the user logs in and which would means the JWT from that login should have the correct "role".

https://fusionauth.io/docs/extend/code/lambdas/jwt-populate

A JWT populate lambda runs whenever a JWT is minted and the reconcile lambda runs whenever a user logs in from an IdP. Which means there is a scenario if a user is logged in on both networks at the same time, it would not be accurate since the JWT from both sessions would be reading from user.data which got updated by the last IdP login. Something like the following feature would also likely be enough to solve this problem for you, we have a similar field on Webhooks but not in JWTs or Lambdas which would detail which IdP used to login.

https://github.com/FusionAuth/fusionauth-issues/issues/1483

Currently, FusionAuth lambdas cannot call the API without including an API key in the code — there’s no built-in secret manager for this yet (feature request).

Alternative approaches:

Webhook filtering (recommended)
Use the user.login.success webhook to check if the user is linked to an IdP, and reject the login by returning a non-200 response. This avoids storing API keys in lambdas, but adds an extra network call to each login.

Store link data in user.data
Push IdP linking info into a custom user.data.links[] field so it’s accessible in most lambdas without needing an API call. You’ll need a process to keep this data current.

Great question—this often causes confusion.

In FusionAuth, logging in after a Forgot Password flow is tracked as ONE_TIME_PASSWORD. That’s because, technically, FusionAuth uses a one-time password during that process. For example, if you look at the Change a User’s Password API, it returns a one-time password token. On the hosted pages, FusionAuth automatically consumes this token to sign the user in immediately after they reset their password via the forgot password link in their email.

So even without traditional OTP or MFA configured, these login events can appear as ONE_TIME_PASSWORD due to password reset flows.

FusionAuth provides an API to search for webhook event logs, including failed events. For example, you can use this endpoint:

/api/system/webhook-event-log/search?start=<timestamp>&end=<timestamp>&eventResult=Failed

This will return all webhook events in the specified time frame that failed. More details are here:
Search Webhook Event Logs

In the API response, the event section contains the original payload that was sent. While FusionAuth doesn’t currently have a built-in replay feature, you can extract this event data and manually re-send it to the webhook URL using your own REST calls.

A native replay feature is on the roadmap, but there’s no confirmed timeline for its release yet.

Yes, FusionAuth provides this information via the authenticationType claim in the JWT. This claim indicates the authentication method used, such as PASSWORD, GOOGLE, SAML, etc.

How to Access Authentication Type:

From the JWT: The authenticationType claim is included in the JWT access token. Documentation: JWT Access Token Claims From a Webhook Event (Alternative Approach): The same authenticationType value is included in the user.login.success webhook event. This may be useful if your system processes authentication events via webhooks instead of decoding JWTs. Documentation: User Login Success Webhook

For additional details on JWT structure and claims, refer to: JWT Components Explained

Yes, FusionAuth provides this information via the authenticationType claim in the JWT. This claim indicates the authentication method used, such as PASSWORD, GOOGLE, SAML, etc.

How to Access Authentication Type:

From the JWT: The authenticationType claim is included in the JWT access token. Documentation: JWT Access Token Claims From a Webhook Event (Alternative Approach): The same authenticationType value is included in the user.login.success webhook event. This may be useful if your system processes authentication events via webhooks instead of decoding JWTs. Documentation: User Login Success Webhook

For additional details on JWT structure and claims, refer to: JWT Components Explained

@pyroseza

So it sounds like you're trying to figure out a way to know when FusionAuth has completed startup.

The webhook is one way to do that. As you said, you can set up a kickstart event webhook within a kickstart file.

Another way is to poll for a known value, such as a non-default tenant that you know your setup has added. That may be a simpler solution for you.

Either way, you'll have to write some code to kick off the testing once you receive a signal that FusionAuth is ready.

I personally would have preferred if there was an API endpoint I could query is to whether or not the kickstart has completed successfully, but instead we were given a webhook and I'm not quite sure how I should be using it.

You'll need to write a webhook receiver that will kick off your tests (or whatever the next step of your testing setup is). I'm not quite sure how do that in one github action, but it should be pretty easy to split up a github action into two actions, a setup one (where you set everything up, including FusionAuth) and a test action (which you kick off in response to the FusionAuth webhook firing).

I think you'd want the workflow_call event: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_call

@muravyov-alexey Thank you!

That is correct. Each time a user is updated, a user.update event is fired, or a user.registration.update (if a registration is updated).

@brian_ls

Thanks for the contribution! I am sure that it will be useful to others along the way!

Thanks,
Josh

An FYI for anyone reading this in the future. The kafka integration does have been revised and include a docker based example.