The /api/user/registration endpoint can be problematic when called concurrently for the same user. FusionAuth recommends using sequential calls.

Recommendation: Make your registration calls sequentially, one after another, even though it may take slightly longer. This ensures data consistency and avoids potential conflicts or failures during the registration process.

There is currently no single API call to atomically register a user to multiple applications. Each registration to an application requires a separate API call, and sequential execution is the safest approach.

Related Documentation User Registration API - Overview of the registration API and available operations Create a User Registration (for an existing user) - API documentation for creating registrations Registrations Core Concept - Understanding the relationship between Users and Applications Applications - Core concepts about Applications in FusionAuth Registering a user to other applications during registration - Community discussion on this topic

The postMethod variable can be null or missing in certain scenarios (such as when a verification link is clicked multiple times), causing the FreeMarker template to fail.

To fix this, you need to provide a safe fallback for the postMethod variable. Update line 16 in your registration/verify.ftl template from:

[#if verificationId?? && postMethod]

To:

[#if verificationId?? && (postMethod!false)]

The !false syntax provides a default value of false when postMethod is null or missing, preventing the FreeMarker exception.

Steps to apply the fix:

Navigate to Customizations → Themes in the FusionAuth admin UI Edit your theme Locate the registration/verify.ftl template Update the conditional check as shown above Save the theme

This pattern can be applied to other templates where variables might be null or missing in certain execution paths.

Why this happens:

According to the FusionAuth documentation, the postMethod variable is not a standard template-specific variable for the /registration/verify template. It is typically available on other verification templates like /email/verify (where it defaults to true). The registration verify template is rendered when a user clicks the URL from the verification email and the verificationId has expired or is invalid. In these scenarios, postMethod may not be set in the template context, which causes the FreeMarker error when attempting to evaluate it as a boolean.

Related Documentation Theme Template Variables - Verify Registration - Documents the variables available in the registration verify template Theme Template Variables - Email Verification - Shows that postMethod is documented for email verification but not registration verification Theme Template Variables - Complete reference for all template variables across different templates

Currently, FusionAuth does not support forcing the register screen when prompt=login is used with an active SSO session. The screen_hint parameter (like Auth0's screen_hint=signup) is not available in FusionAuth.

Workarounds:

Clear the SSO session before registration: You can clear the existing SSO session in your proxy/middleware before redirecting to oauth2/register. While not ideal, this would allow the registration flow to proceed without the passthrough behavior.

Use direct registration without prompt: If you call the registration endpoint without the prompt=login parameter and there are no missing required fields, FusionAuth will complete the registration directly. Only when there are missing fields will users be sent to the complete-registration page.

Feature Request:

If neither workaround meets your needs, this would require a feature request for FusionAuth to support a parameter similar to screen_hint=signup. The product team would need to review this for the roadmap, though implementation timelines would depend on prioritization.

For now, clearing the SSO session before initiating registration is the most reliable approach to ensure users see the registration screen rather than experiencing passthrough behavior.

Related Documentation OAuth prompt Parameter - Details on the prompt=login parameter and its behavior (available since v1.60.0): OIDC Prompt Documentation OAuth Authorize Endpoint - Complete reference for OAuth authorization parameters including prompt, login_hint, and idp_hint: Authorize API Reference Self-Service Registration - Overview of how self-service registration works and how registrations are created: Self-Service Registration Guide Complete Registration - Information on the complete registration flow when missing fields are present (available since v1.65.0): Complete Registration Documentation Logout and Session Management - How to clear SSO sessions programmatically: Logout and Session Management Hosted Backend API - Documentation on the /oauth2/register endpoint behavior: Hosted Backend API

Note: The /oauth2/register endpoint is not fully documented in the official OAuth endpoints reference. There is an open issue to add complete documentation for this endpoint. When a user has an active SSO session and hits /oauth2/register, FusionAuth redirects them through the authorization flow, which causes the passthrough behavior you're experiencing.

This is the expected behavior in FusionAuth. During first-time registration, when a user completes the MFA challenge (e.g., entering an email-based code), the Last used field for that MFA method is not populated immediately. It remains null after the initial registration flow.

The Last used timestamp is only set on subsequent authentications after the user has been registered. Once the user logs out and logs back in (triggering a new authentication flow), the MFA method's Last used field will populate correctly with a timestamp.

Important clarification:
Even though Last used shows null after registration, the user is still required to complete the MFA challenge during the registration process. The null value does not indicate that MFA was bypassed — it simply means the "Last used" tracking starts from the second authentication onward, not the registration itself.

Regarding registration abuse:
If you're experiencing self-service registration abuse, the null Last used field is not the cause. Consider these mitigation strategies:

Identity Pre-Verification (available since v1.62.0): Use the Identity Pre-Verification Using Email Verification Form feature to require email verification before completing registration.

Third-party identity verification: Implement a self-service registration lambda that calls an external identity verification service via REST API before allowing user creation. Fideo is a documented example, but any identity verification system with a REST API can be integrated.

Rate limiting and CAPTCHA: Consider additional anti-abuse measures at the application level to prevent automated registration spam.

Now I have enough information to improve the answer. Let me create an enhanced version with documentation links.

To grant a user access to the FusionAuth admin UI, you need to:

Create the user in the Default tenant (not a custom tenant) Register them for the FusionAuth application (the built-in admin application) Assign them an appropriate admin role during registration (e.g. "admin" for full access or a more limited role)

The key distinction is that the Tenant Manager Application is intended for granting third-party users limited admin access to manage users and identity providers within a specific tenant (this is an Enterprise feature). For full admin UI access, you must use the FusionAuth application in the Default tenant.

If the user's password setup email is being filtered as spam, you can set a temporary password manually and they'll be prompted to change it on first login.

Steps to add an admin user: Navigate to Users in the Default tenant Create a new user or select an existing one Go to the Registrations tab Click Add registration Select the FusionAuth application Choose the appropriate admin role from the dropdown Save the registration Available Admin Roles

Here are the main admin UI roles you can assign:

Role Description admin Can manage everything, including creating new users with administrator privileges user_support_manager Limited scope — recommended for tier 1 support staff user_support_viewer Can view user information only user_manager Can add and edit users (note: this role has similar power to admin, so use user_support_manager for restricted access) user_deleter Can delete users

Important: A user must have a registration in the FusionAuth application to access the admin UI — group membership alone is not sufficient.

Related Documentation FusionAuth Admin UI Roles - Complete list of admin roles and their capabilities User Support Guide - Detailed guide on creating admin users Default Tenant - Why the Default tenant cannot be deleted and its relationship to the FusionAuth application Tenant Manager Application - Enterprise feature for providing limited admin access to third-party users within specific tenants

This is possible in a couple of ways.

First, to allow users to register for an application on login, you need to turn on self-service registration. From the docs:

When you enable self-service registration for an application and a user who does not have a registration for that application successfully logs in to that application, the user will automatically be registered for that application, and have a registration added.

Then the question becomes, how can you disable the hosted login pages self-service registration form?

To do so, take the following steps:

update your theme to remove the link to the "Don't have an account? Create one" link from any pages, including the login page. You can also remove all the content from the registration themed page and replace it with not implemented or similar. However, a sinister user may still be able to post to the register endpoint and create a user if you are self-hosting, block access to the /register endpoint using a proxy if you are not self-hosting, prevent self-service registration by adding an encrypted secret value to all user accounts you create via the API. Then, create self-service registration validation lambda which will examine the user object. If the user object comes through without the secret value, fail the registration. Otherwise allow it through because it is a user who has logged in.

The self-service lambda may not fire unless there are required fields on the registration form, but that behavior is undocumented and may change.

@ahcfrontdoor I set up an application with the setting you are talking about and was allowed to register and proceed without any re-direction. Can you share a screen shot of your application registration tab. Please be sure to black out any sensitive information if necessary.

@fusionauth-qhj5e I have brought this up internally, for now we are considering adding a PR to make it more clear for users.

https://github.com/FusionAuth/fusionauth-site/pull/2918

@harish_reddy I just want to make sure I understand where you are coming from. If you user signs up with an email address, you want the same response even if they are already signed up? Can you please share some images of how you would like the flow to work? I think this could cause problems and confusion the way I am thinking about it.

@muravyov-alexey Thank you!

@alessandrojcm,

Sounds good. I have logged a bug report; we should have this one squashed soon!

Thanks,
Josh

You can use the user.create or the user.registration.create webhook to do something like this.

If you enable these webhooks and configure the transaction to require the webhook to succeed, then you simply need to return a non-200 status code from the webhook to cause FusionAuth to fail this create.

https://fusionauth.io/docs/v1/tech/events-webhooks/#tenant-settings
https://fusionauth.io/docs/v1/tech/events-webhooks/events/#user-create
https://fusionauth.io/docs/v1/tech/events-webhooks/events/#user-registration-create

Hi @tl-fa,

You can view our Roadmap Guidance regarding how features are implemented into FusionAuth. A good snapshot of current development can be found here as well.

We will certainly update any related issue cards as development moves forward!

Thanks!
Josh

Yes, if self service registration is enabled (which is set on an application by application basis) and a user who is already logged in to FusionAuth tries to register for such an application, FusionAuth will automatically register them for the app. It also checks that all required profile information is filled out, which is why adding the required field displays the registration form.

This functionality doesn't exist in the FusionAuth admin screens, please feel free to file an issue with a detailed use case if you feel it should.

For registrations, you can look at the date the application registration was created using the User Search API. You'll probably want to use a date range.

For logins, you can review and search all login records by going to "System -> Login Records". However, one could build something with more granularity using the FusionAuth APIs.

This API documents how to pull down the log in data for a given date range. This doesn't include the full user object, but does include the user id. From there you could use the user api to pull down the entire user object.

Also, please note that login records may be deleted after a certain period of time, based on your system settings. This deletion is controlled in the admin UI, under "Settings -> System -> Advanced -> Login record settings" and would impact your ability to query login data in the past if enabled.

Yes, just confirmed the fact that this is a Safari only issue. Only Safari seems to be doing this, we don’t return a 403 so this must a CORS failure. Perhaps Apple is sending additional headers on the request when using Safari that need to be accounted for in the Allowed headers.

I added GET to the allowed methods for CORS and it works that seems to allow it to work in Safari. Please test and let me know.

The redirect workflow looks to be different in Safari when using native controls vs Chrome or other browsers.

Please see this issue for updates on this functionality. Vote for it if this is important to you.

Hi, I have the same problem here. The tenant's SMTP setting are correct and test emails are successfully delivered. I'm evaluating the FusionAuth right now and often delete/re-register users with the same emails. Verification emails are delivered to all users but one. The only thing that distinguish the problem user from the others is the fact I initially registered him via Facebook identity provider, so his email was automatically verified. After that I deleted the user and trying to register with just email (not Facebook). And emails are not delivered. Manually sent SMTP test emails to that address also delivered successfully. I hope this help to investigate.

Is this what you are looking for?: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-and-registration-combined

That API does return a token as of v1.17.0.

Our validation takes in inverse approach. The setting is actually to require a non-alphanumeric character. So any character that is not alphabetic, or a digit, will satisfy this requirement.

There is not a fixed set of symbols as this would reduce the password entropy, which is generally a bad idea.