@nate Can you successfully Send test email from Tenants -> Select Edit from desired Tenant -> Email in the AdminUI? This will test if your SMTP settings are correct.

@ezequiel-rebasa said in Unable to Obtain Tenant-Signed Access Token for Data-Plane Apps in a Multi-Client, Multi-Application FusionAuth Architecture:

prompt=none

OK a few things. One is it looks like there are a few open issues #521 and #2208 around FusionAuth not supporting the "prompt=none" parameter.

I may be missing something here, but using lambdas, I as able to hit the login event for both Tenants when logging in. I image you could make the changes you needed there.

I set up FusionAuth so that I have 2 Tenants Default and Test Tenant.

In Default there is the FA Login Master application.

I the Test Tenant I have the ExampleDotNetApp application.

I set up an Identify Provider named FusionAuth Default Tenant FA Login Master using the FA Login Master application as the (IdP) and enabled it on the Test Tenant ExampleDotNetApp. I created a lambda named "FA Default OpenID Reconcile" of type OpenId Connect reconcile.

The order the Lamda's were executed were as follows:

• "FA Default Access Token Populate" of type JWT populate on FA Login Master

• "FA Default OpenID Reconcile" on FusionAuth Default Tenant FA Login Master

• "ExampleDotNetApp Access Token Populate" of type JWT populate on ExampleDotNetApp.

You could use potentially use any of those to inject info you need on the JWT.
**Please not that Lambda HTTP Connect is only available in an Essentials or Enterprise plan.

When I add a favoriteColor in the "ExampleDotNetApp Access Token Populate" lambda, I am able to see it in the ExampleDotNetApp application after logging in.

I would think with the access to those lambdas, you may be able to accomplish what you are trying to do.

This seems like a bit of a complex use case. To start off, let's clarify, FusionAuth allows the creation of multiple Tenants within the AdminUI. However, the user created under each tenant has a unique id. So user1@example.com under the Tenant One tenant is different than the user1@example.com under the Tenant Two tenant.

That being said, I don't don't think that is the issue. The way I understand this is the Simfinix tenant is in FusionAuth and that is going to be the IdP for all applications. In that case, you will have to set up the Simfinix tenant as an Identity Provider in FusionAuth (Here is a link to a post that shows how this can be done). Then each of your applications in the other tenants will have to use that IdP. Be sure to check out the linking strategies to get the behavior you want. Then you can run the lambdas you need for the applications.

If anyone has other ideas, please feel free to chime in.

@pocfused said in Email verification fails in new incognito mode:

https://fusionauth.io/community/forum/topic/1406/link-in-email-verification-not-working-first-time

Glad you were able to solve your issue.

As far as the automatically verify the email part. What settings do you have for Applications -> Your Application -> Registration -> Verification strategy? There is a setting Clickable link. Is that what you are after?

Another thought would simply turning off Verify registrations in the Applications -> Your Application -> Registation tab work for you or do you still want the user to actually have to click on a link? (It would make sense to ensure the user owns the email address.)

You could also do something like provide a custom template and direct them to your application and then automatically verify them using the APIs. Check out this blog post.

Good luck.

First check out the information you are getting from the docker log. Look at the log from the spin up and search for "kickstart." Was the container able to find the kickstart.json file? (In this case yes.)

If the kickstart file was found, continue searching through the log for a potential error in the running of the kickstart. You might see something like.

fusionauth-1  | 2025-07-02 05:14:05.177 PM ERROR io.fusionauth.api.service.system.kickstart.KickstartRunner - Failed to execute request to [PATCH][/api/user/registration/000000000001] Status [404]
fusionauth-1  | Request body:
fusionauth-1  | {
fusionauth-1  |   "registration" : {
fusionauth-1  |     "applicationId" : "e72dca1d-626c-4f4b-8f36-b7c8c2c0af33"
fusionauth-1  |   }
fusionauth-1  | }
fusionauth-1  | 2025-07-02 05:14:05.177 PM ERROR io.fusionauth.api.service.system.kickstart.KickstartRunner - Error response:
fusionauth-1  | null

This will let you know there was an error and you need to resolve it. In this specific case, The PATCH request should have been a POST. Once that was changed, the kickstart ran fine.

When trying to create a kickstart, it's not getting used when i run docker compose. How can I fix it?

@jakub-hajto , you may want to check out the Google Reconcile Lambda documentation. I also found this post that may be useful for you.

@pocfused What versions of FusionAuth are you using? I saw this post that may account for this issue.

@sergey_smirnov OK. It doesn't seem like the webhook you are using would cause the duplicate logins. I came across this post stating that exchanging a refresh token counts as a login event. I'm wondering if something like the user logins in using a new tab, then goes back to the old tab that triggers a refresh. If that is the case, that could account for the delay between logins and the "Something doesn't seem right" message as that session is no longer valid because of the new login. You might be able to verify this by using a webhook. There is a JWT.Refresh event that you might be able to log somewhere to see if it fires around the time of the duplicate log ins.

@sergey_smirnov OK, I did some investigating and here is what I have found.

1. SSO, I saw a reference to a post that mentions using SSO will create multiple session records (but shouldn't necessarily cause multiple login events). Are you using SSO?

2. Are you using any Lambda's? In some versions (notably 1.31.0), a bug caused the OIDC reconcile lambda to be called twice during certain identity provider logins, which could result in duplicate processing and potentially duplicate events. This was patched in version 1.32.1.

3. Are you using any Webhooks?

4. Are you using an external IdP?

These are just a couple of things to consider.