Not as a single feature, but doable with some glue code. FusionAuth has no built-in “inactivity warning” workflow or scheduler for this.

It does give you the pieces: a lastLoginInstant on every user, a user search API, an email send API, and user deactivation. You wire them together with a small scheduled job (cron, Lambda, GitHub Action, etc.) outside FusionAuth.

Set up a daily job that does three things:

Finds users whose last activity was about 55 days ago and who haven’t been warned yet. Sends them the warning email and records that you did. Finds users who are 60+ days inactive and marks them dormant.

If a user logs in during the 5-day window, their lastLoginInstant updates and they drop out of the step 3 query automatically.

Use the User Search API with an Elasticsearch/OpenSearch query on lastLoginInstant (milliseconds since epoch). This needs the Elasticsearch/OpenSearch search engine. The database search engine doesn’t support range queries on this field.

POST /api/user/search { "search": { "numberOfResults": 500, "query": "{\"bool\":{\"must\":[{\"range\":{\"lastLoginInstant\":{\"lt\":1760000000000}}}],\"must_not\":[{\"term\":{\"data.dormantWarningSent\":true}}]}}" } }

Compute the lt value in your job as now - 55 days (so replace 1760000000000). Users who have never logged in won’t have a lastLoginInstant, so decide whether to fall back to insertInstant for them.

You can use FusionAuth to send the email or your own system. If you choose the former, create an email template in Customizations → Email Templates, then call the Send Email API with the matching user IDs:

POST /api/email/send/{emailTemplateId} { "userIds": ["<id1>", "<id2>"], "requestData": { "daysInactive": 55, "daysUntilDormant": 5 } }

Your template body can then use FreeMarker:

Hi ${user.firstName!"there"}, As part of our routine account security measures, we monitor accounts for inactivity. We haven't detected activity on your account in the last ${daysInactive} days, and it is scheduled to be marked dormant in ${daysUntilDormant} days unless activity is detected. Log in to keep your account active: https://login.example.com

requestData values are available at the top level of the template, so you can reuse the template if you change the thresholds later.

After a successful send, patch the user to record that they've been notified so you don't send them multiple emails:

PATCH /api/user/{userId} { "user": { "data": { "dormantWarningSent": true, "dormantWarningSentAt": 1760000000000 } } }

The must_not clause in the search query above then skips them. If the user logs in, clear the flag so they can be warned again in the future. A user.login.success webhook receiver that uses the API is a clean place to do that.

As far as what you actually do when the user is marked dormant, you have two options:

Deactivate the user. DELETE /api/user/{id} (soft delete) sets active=false, which blocks login. To reactivate, call PUT /api/user/{id}?reactivate=true. Deactivation also fires a user.deactivate event that you can consume via webhook to notify downstream systems. Flag only. Set user.data.dormant = true and handle it in your app where you might do a step-up or force an account recovery. This is gentler and keeps the account usable after a step-up.

For a true “close the account” outcome, deactivate first. Hard-delete (?hardDelete=true) only after a retention period that satisfies your compliance requirements.

Caveats:

lastLoginInstant updates when a user authenticates. Silent token refreshes using an existing refresh token don’t necessarily count as logins, so a user with a long-lived session in your app could look inactive. If that matters, track your own activity timestamp in user.data (updated by your app or a webhook) and query that instead. Test this against your own setup before relying on it.

user.lastLoginInstant is global to the user within a tenant. Each registration also has its own lastLoginInstant (user.registrations[].lastLoginInstant). If “inactive” should mean inactive in a specific application, query on that field and filter by applicationId.

Run the job daily and use a window, not an exact day match, so a missed run doesn’t skip anyone.

Page through search results (startRow) rather than assuming one page covers everyone.

Test with a user whose lastLoginInstant you’ve backdated in a non-production tenant.

Make sure your Send Email API key has only the endpoints it needs (search, send email, patch user, deactivate).

You want to use FusionAuth webhooks to push data into your pipelines. I imagine the JSON will differ, so you might need to modify your mapping layer, but we should be able to provide the data you expect.

Here's our general webhook documentation.

Some events you might be interested in:

User login success which includes the authentication method User login failure Two factor method added User create

Where possible, avoid transactional webhooks because you're using this for analytics and transactional webhooks impact workflow duration negatively.

You can also use the Search API to get adhoc counts/true things up, but it won't necessarily have the richness of data of the webhooks.

@damien For information on releases, please be sure to check out the release-notes. While it may not list which versions the issues were introduced in, it is recommended to stay on the latest version to avoid potential issues.

FusionAuth Cloud can add IP addresses to your instance's allow list if they meet the following criteria:

Static: The IP address must be static and not change without notice. Owned by your organization: The IP must be allocated to your company's infrastructure, not shared with other companies or resources (such as through a CDN). Associated with production servers: The IP must be used by production servers, not developer laptops or office networks.

Once you confirm your IP addresses meet these criteria, open a support ticket through your FusionAuth account portal with:

The list of IP addresses to be added Confirmation that each criterion is met The FusionAuth Cloud hostname your application connects to

FusionAuth will then add the addresses to your allow list. Note that if you use shared network infrastructure (like NAT gateways), all traffic from that infrastructure will share the same outbound IP, which is acceptable as long as the criteria above are met.

Important notes:

Allow list changes typically take two to three business days to implement Adding IPs to the allow list helps prevent 429 response codes and CAPTCHA challenges that may occur due to FusionAuth Cloud's rate limiting protections If you no longer need an IP address on the list, you can submit a support ticket to have it removed Related Documentation FusionAuth Cloud CAPTCHA and Rate Limits - Detailed information about IP allow lists and rate limiting FusionAuth Cloud Support - How to access support for your FusionAuth Cloud deployment FusionAuth Cloud Deployment IP Addresses - Information about IP addresses for your FusionAuth Cloud instances

Yes, you can use FreeMarker logic in FusionAuth email templates to dynamically customize content per tenant without duplicating templates.

Solution

Store tenant-specific branding data in the tenant.data field (custom JSON). For example:

{ "branding": { "logoUrl": "https://cdn.example.com/acme/logo.png", "primaryColor": "#0057b8", "buttonTextColor": "#ffffff", "subjectPrefix": "[Acme]", "supportEmail": "help@acme.com", "companyName": "Acme" } }

Then reference this data in your email templates using FreeMarker syntax. Here's an example for email verification:

[#assign b = (tenant.data.branding)!{}] [#assign color = b.primaryColor!"#333333"] <div style="font-family: Arial, sans-serif;"> <img src="${b.logoUrl!'https://cdn.example.com/default-logo.png'}" alt="${b.companyName!tenant.name}" height="40"> <p>Hi ${user.firstName!'there'},</p> [#if verificationOneTimeCode??] <p>Your verification code:</p> <p><strong>${verificationOneTimeCode}</strong></p> [#else] [#assign url = "${baseUrl}/email/verify/${verificationId}?client_id=${(application.oauthConfiguration.clientId)!''}&tenantId=${tenant.id}"] <a href="${url?html}" style="background:${color}; color:${b.buttonTextColor!'#ffffff'}; padding:12px 24px; text-decoration:none; border-radius:4px;"> Verify email </a> [/#if] </div> How it works [#assign b = (tenant.data.branding)!{}] safely extracts the branding object or defaults to an empty object ${b.logoUrl!'default-value'} provides fallback values if a property is missing The same template works across all tenants, pulling each tenant's specific branding from tenant.data

This approach works for all FusionAuth email templates (email verification, forgot password, email MFA). The complexity and depth of customization you can achieve depends on your specific needs, but this pattern handles most common branding requirements.

There's no form for editing tenant data, but you can do so using one of the client libraries and your own custom form.

Unfortunately, Passkeys cannot currently be used as an MFA method in FusionAuth's native hosted MFA flow. There is an open feature request for this functionality.

Workaround

You can implement a step-up authentication pattern using FusionAuth's WebAuthn API:

After the user completes email + password login, your application calls /api/webauthn/start The authenticator produces a signature Your application calls /api/webauthn/assert to verify possession of the passkey Only grant access if the assertion succeeds

You can check whether a user has a registered passkey by calling /api/webauthn?userId={userId}.

Important limitation: This workaround runs in your application code, not inside FusionAuth's hosted MFA screen. Passkeys will not appear alongside email and authenticator app in the same native picker — you would need to build that UI and enforcement logic yourself in your application.

A feature request has been logged for native passkey MFA support in FusionAuth's hosted flow.

Related Documentation Authentication With WebAuthn & Passkeys - Complete guide to implementing WebAuthn/passkeys in FusionAuth WebAuthn API Reference - API endpoints for starting and completing WebAuthn authentication ceremonies Start a WebAuthn Passkey Assertion - Documentation for the /api/webauthn/start endpoint Retrieve a Passkey - How to check if a user has registered passkeys using /api/webauthn?userId={userId} Multi-Factor Authentication (MFA) - Overview of FusionAuth's native MFA methods (TOTP, email, SMS) Step-Up Authentication - General guidance on implementing step-up auth patterns in FusionAuth Can I do a step up authentication with WebAuthn/passkeys? - Community discussion on this exact use case

Unfortunately, the passwordless login code TTL cannot be configured per application—it is only available as a tenant-level setting in FusionAuth. The default TTL is 180 seconds, and this is configured via tenant.externalIdentifierConfiguration.passwordlessLoginTimeToLiveInSeconds.

Here are two potential workarounds:

1. Separate Tenants

Since the setting is per tenant, you could place applications that require different code lifetimes into separate tenants. Note that this means users and configuration will be isolated per tenant, so carefully evaluate whether this trade-off fits your architecture.

2. Build Your Own Passwordless Flow

You can implement custom code expiration logic by using the passwordless API directly:

Start the login with /api/passwordless/start Deliver the code through your own mechanism Track when you issued each code in your application Enforce your desired per-application expiry by rejecting codes that are too old before calling the completion endpoint Complete the login with /api/passwordless/login

With this approach, the tenant-level TTL acts as the maximum lifetime, but your application logic can enforce shorter, application-specific expirations as needed.

This is not a built-in FusionAuth feature, so if per-application passwordless code TTL is important to your use case, consider submitting a feature request on the FusionAuth GitHub issues page.

Related Documentation Passwordless Login Overview - General overview of passwordless authentication in FusionAuth Magic Links Guide - Details on magic links and one-time code customization, including TTL configuration Passwordless API - Complete API reference for building custom passwordless flows Start Passwordless Login API - API to generate a passwordless code Complete Passwordless Login API - API to complete the passwordless login Tenant Configuration - Tenant-level external identifier settings including passwordless login TTL

FusionAuth supports customization for some of these scenarios through themes, but not all:

1. Root Path Customization

This is possible. The Index page can be customized through your FusionAuth theme. You can add a redirect (for example, using JavaScript or a meta refresh tag) to send users to your application's login page.

Important: When FusionAuth can't identify the tenant (including when browsing to / without client_id or tenantId parameters), it uses the default tenant. To theme the root page:

Create a copy of the built-in theme — the default theme is immutable because it ships with FusionAuth Edit the index template in your copy to include your redirect (using JavaScript like window.location.href = "https://yourapp.com/login" or HTML meta refresh) Apply this theme to ALL tenants, including the default tenant Test with tenant specified — try the root URL with tenantId or client_id to confirm your edited theme renders

See the Advanced Themes troubleshooting guide for more details on theme issues.

Related: GitHub Issue #378

2. OAuth Error Handling

This is also possible. The OAuth error page can be customized in your theme, so you can implement the same redirect approach for customers who saved stale or broken login links. The OAuth error template is available for customization and you can add JavaScript or meta refresh redirects to handle these scenarios.

Note that OAuth errors can also be returned as redirect parameters to your application's callback URL (depending on the OAuth flow), which allows your application to handle errors directly rather than showing the FusionAuth-hosted error page.

3. 404 Pages for Invalid URLs

This is NOT currently customizable. The 404 page cannot be customized, including on Cloud deployments. Requests to invalid paths (like /whatever) will show the default error page. This is a known limitation tracked in GitHub Issue #404, which requests additional themed error pages (including 404 and 500 pages).

Summary

You can handle root path and OAuth error redirects through theme customization by adding JavaScript redirects to the index and OAuth error templates. However, true 404 pages remain uncustomizable. CloudFront configuration is not exposed to customers on cloud deployments, so there's no workaround at that layer.

Related Documentation Advanced Themes Documentation - Complete guide to customizing FusionAuth themes Theme Templates - Full list of available templates including Index and OAuth error Theme Template Variables - Variables available in each template Index Template Variables - Specific to the root page OAuth Error Template Variables - Specific to OAuth error page OAuth Error API Documentation - How OAuth errors are returned Default Tenant Configuration - Understanding the default tenant

The Helm chart for FusionAuth 1.53.4 has been released and should now be available in the FusionAuth charts repository.

In the meantime, if you need to deploy a specific FusionAuth version before the corresponding Helm chart is released, you can override the image tag in your Helm values file:

image: tag: "1.53.4"

This allows you to use the latest Helm chart while specifying the exact FusionAuth Docker image version you need.

Related Documentation Deploy with Kubernetes - Helm Chart Configuration - Complete guide on configuring and deploying FusionAuth using Helm charts Deploy FusionAuth to the Cluster - Instructions for installing and verifying your Helm deployment Kubernetes Overview - Overview of FusionAuth on Kubernetes with architecture diagrams Upgrade FusionAuth - General guidance on upgrading FusionAuth installations

When you override the image tag in your values.yaml file, you can verify the correct version is deployed by checking the IMAGES column in your Kubernetes deployment:

kubectl get deployments -o wide

The rate limiting you're encountering is applied at the WAF (Web Application Firewall) level on FusionAuth Cloud, not from the FusionAuth application itself. These rate limits protect customers and are standard across all FusionAuth Cloud deployments.

Rate Limit Configuration

FusionAuth does not publish rate limits publicly and they are subject to change.

Please open a support ticket to obtain more guidance.

Whitelisting for Performance Testing

Since these are network-level rate limits, they cannot be configured within your deployment. However, IP allow listing is available to bypass rate limiting for performance testing if your IP address meets these requirements:

It is static It is owned by your company (not shared infrastructure like a CDN) It is associated with a production server (not a developer's laptop)

If you can provide a static IP address that meets these criteria, you can open a support ticket to get it allow listed. Note that allow list changes typically take two to three business days to implement.

Best Practices for Performance Testing

When planning load or performance tests against FusionAuth Cloud:

Open a support ticket before testing to notify the FusionAuth team of your planned stress test window Don't use Basic cloud deployments for performance testing, as they run on limited infrastructure and results won't be representative. Use a Business or High-Availability plan instead, which you can spin up, test, and tear down as needed Implement exponential backoff when you receive a 429 response - this is the recommended approach for handling rate limits gracefully Distribute requests over time rather than sending bursts of traffic Alternative Testing Approaches

If you cannot obtain an allow-listable static IP address (such as for developer machines or CI/CD pipelines), consider:

Running a self-hosted FusionAuth instance for automated testing, which gives you full control over rate limiting configuration Using smaller-scale testing that stays under the rate limits Related Documentation FusionAuth Cloud - CAPTCHA and Rate Limits FusionAuth Cloud - Load Testing Troubleshooting FusionAuth Cloud API Calls User Search API Documentation Advanced Threat Detection - Customizable Rate Limiting (for application-level rate limits within FusionAuth)

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

This issue was caused by a bug that existed prior to version 1.68.0. In earlier versions, there was a problem where LDAP connectors scoped to specific domains could incorrectly be called (or not called) for users outside those domains. This could result in the connector appearing to stop functioning entirely after an upgrade.

Solution:

Recreate the LDAP connector configuration. When doing so, verify the Domains field:

If you need the connector to apply to all users, use a wildcard (*) for the domains. If you need domain-specific scoping, explicitly configure the same domains you had previously.

This bug was fixed in FusionAuth 1.68.0. See the release notes for details:

Fixed an issue where Connectors configured for a specific domain in a Tenant could be called for users outside of that domain.

If you encounter this issue after upgrading to 1.68.0 or later and recreating the connector does not resolve it, verify:

Debug mode is enabled for both the connector and the reconcile lambda. The LDAP server is reachable from the FusionAuth instance. Event log and system log (fusionauth-app.log) for any connection or authentication errors.

The user.login.suspicious webhook event requires the Client Risk Configuration to be enabled at the tenant level. Even though Risk Signals are evaluated by default, the webhook event itself won't fire unless this configuration is explicitly turned on.

To enable it:

Navigate to Tenants → Select your tenant → Edit → Security tab Find the Client Risk Configuration section Ensure it's enabled for your tenant

Additionally, verify that the user.login.suspicious event is enabled in the tenant's webhook settings:

Go to Tenants → Select your tenant → Edit → Webhooks tab Confirm user.login.suspicious is checked/enabled

Once both are configured, your webhook should start receiving user.login.suspicious events along with details about which Risk Signals triggered the suspicious login determination.

About Risk Signals and Email Volume

If you're seeing a significant increase in suspicious login emails after upgrading to 1.68.0 or later, this is because FusionAuth introduced comprehensive Risk Signals in version 1.68.0. Previously, only Impossible Travel was tracked. Now additional signals are evaluated including:

Untrusted Device Unrecognized Device Recent Password Change Recent Identity Change Dormant Password Suspicious Agent

All Risk Signals are enabled by default without any configuration changes.

Managing Email Volume

You can tune which Risk Signals trigger suspicious login alerts:

Go to Tenants → Select tenant → Edit → Security tab → Client Risk Configuration Disable specific Risk Signals that are generating too many false positives for your use case Monitoring Without Sending Emails

You can monitor webhook events while tuning your Risk Signals without sending emails to users:

Go to your tenant/application settings → Identities tab Change the Suspicious Login template to "No Template Selected" Monitor your webhook endpoint to see which Risk Signals are triggering Fine-tune your Risk Signal configuration Re-enable the email template once you're satisfied with the detection accuracy

The webhook fires whenever a Risk Signal threshold is met, independent of whether an email template is configured. This allows you to observe and tune the system before alerting end users.

Yes, you need to create two separate applications within the same tenant in FusionAuth. Here's how to configure this:

Configuration Steps

Create both applications in the same tenant - Users are scoped at the tenant level, so applications in the same tenant can share authentication state through FusionAuth's SSO session.

Enable self-service registration on the second application - This ensures a seamless login experience. When a user navigates to the second application while already authenticated to the first, they will be automatically registered and logged in.

How It Works User logs into the first application at your registration URL to create their account. Make sure the rememberDevice parameter is true or checked. You can modify your theme to hardcode that value. While that session is valid, they navigate to the second application's login URL They are automatically registered and authenticated to the second application without manual intervention

The key to this working is that FusionAuth creates an SSO session at the tenant level when a user logs in and rememberDevice is checked. When the authenticated user tries to access the second application, FusionAuth recognizes the existing SSO session and automatically creates a registration for that user in the second application (when self-service registration is enabled).

Password Reset Behavior

Because users are scoped at the tenant level, a password reset applies to all applications under that tenant. Users can utilize the password reset page for the first application and will be able to log in at the second application with the new password.

Sharing Templates

Both applications can share the same theme and templates. Themes are assigned at the tenant level (though you can also assign application-specific themes if needed starting with FusionAuth 1.27+). This means you can configure one set of templates - including password reset, login, and user management pages - that will be used by both applications.

Pre-creating User Accounts

If you create user accounts ahead of time, you can automatically include the registration for the second application when creating the users. This would mean adding that application to their registrations when you create the account initially using the Create a User and Registration API.

Related Documentation Implementing Single Sign-On - Complete guide to configuring SSO between applications Self-Service Registration - How automatic registration works when SSO is enabled Create a User Registration API - Programmatically register existing users to additional applications Application Themes - Configure application-specific themes if needed Themes Documentation - Customize and share login pages and templates across applications

FusionAuth tenants provide logical isolation, not physical isolation. While users, applications, groups, and configuration are logically separated per tenant, all tenants in an instance share the same FusionAuth nodes, database, and search index.

This means that while importing data into one tenant will not impact the data integrity in another tenant, it does draw on the same compute and database capacity that other tenants' logins and profile updates use. Large imports can potentially affect performance across all tenants.

Recommendations to minimize impact:

Serialize imports: Do not run multiple imports simultaneously. Even when migrating multiple clients, avoid having two clients in the initial import phase at the same time.

Pre-hash passwords: Since you're already sending passwords with hash, salt, factor, and encryption scheme, this will significantly reduce load during imports. If passwords were sent as plaintext, FusionAuth would need to hash each one on import (which can take several hundred milliseconds per user).

Start with smaller batches: Rather than immediately using 100k user batches, start smaller to monitor system performance during imports. If performance is acceptable, gradually increase the batch size until you find the right balance between performance and import speed.

Avoid transactional webhooks: You mentioned using Kafka integration instead of custom webhooks, which is good. Ensure you are only using the Kafka integration for events and not using any transactional webhooks, as these can add additional load during imports. Transactional webhooks block the operation until the webhook completes, which can significantly slow down bulk imports. Non-transactional events (like those sent to Kafka) are fire-and-forget and don't block the import process.

Limit concurrent operations: You mentioned planning to run only one import call at a time from one worker, which is the right approach. Updates using the PATCH endpoint can occur in parallel as they should be infrequent.

Monitor database performance: Keep an eye on your database connection pool and query performance during imports. The shared database is typically the bottleneck in multi-tenant scenarios under heavy load.

By following these practices, you can minimize the impact of bulk imports on other tenants in your multi-tenant FusionAuth deployment.

Related Documentation Multi-tenancy Guide - Overview of FusionAuth's multi-tenant architecture and concepts Levels of Isolation - Explanation of logical vs. physical isolation in FusionAuth Import Users API - API documentation for bulk user imports Password Hashes - Details on importing pre-hashed passwords to improve performance Transactional vs. Non-Transactional Events - Understanding event types and their performance impact Kafka Integration - Using Kafka for non-blocking event processing Scaling Your Auth - Best Practices - Performance and scaling considerations for authentication systems

At this time, FusionAuth Cloud does not support customizing HTTP security headers on individual tenant deployments. There is an existing GitHub feature request tracking this capability, but it is not currently on the roadmap and no ETA is available for when this might be added.

If you are running a self-hosted FusionAuth instance, you can configure these headers using a reverse proxy (nginx, Apache, etc.) in front of FusionAuth. For FusionAuth Cloud customers, this configuration is managed at the infrastructure level and cannot be modified per-tenant.

You may want to subscribe to or comment on the relevant GitHub issue to track progress on this feature request.

This is a known bug in FusionAuth 1.69.x that affects the System Logs page when viewing logs from multiple nodes in a cluster.

The issue has been confirmed and logged with the FusionAuth development team. The 401 errors occur when the UI attempts to fetch log content from other nodes in the cluster, causing the tab-switching functionality to fail intermittently.

Unfortunately, there is no workaround available at this time. The bug will be addressed in a future release.

As a temporary measure, you may need to:

Refresh the page multiple times when checking logs across nodes Navigate away from and back to the System Logs page to trigger a reload Access logs directly from individual nodes if you have that capability in your deployment

Once this issue is resolved in a future version, the System Logs page should reliably display logs from all nodes without authentication errors.

FusionAuth does not have a direct passthrough option to prevent storing user data from social login providers. However, there are several approaches to handle this:

Option 1: Use a Reconcile Lambda (Recommended for Social Login)

For social login providers like Google, you can use a reconcile lambda to intentionally overwrite the user data with placeholder values before it's permanently stored:

function reconcile(user, registration, idToken) { // The idToken is the response from the tokeninfo endpoint // https://developers.google.com/identity/sign-in/web/backend-auth#calling-the-tokeninfo-endpoint user.firstName = "Purposely not set"; user.lastName = "Purposely not set"; user.fullName = "Purposely not set"; user.imageUrl = "http://www.notset.com"; }

This ensures that personal data from the social provider is replaced immediately during the reconciliation process.

Option 2: Minimal Registration Form

For new user registrations (non-social), configure your registration form to collect only email and password, avoiding the collection of first/last name entirely.

Option 3: Use Webhooks to Clear Data

Implement a user.create.complete webhook that listens for new user creation events, then use the FusionAuth User API to clear the personal data fields and move them to your profile service. Note that this approach means user data will briefly exist in FusionAuth before being cleared.

Option 4: Lambda with External Fetch (Advanced)

You could use lambdas with fetch calls to move data to your profile service and set FusionAuth fields to null. However, this introduces latency due to network calls during authentication flows.

For Existing Users

If you already have users with stored data, use the User API to programmatically clear the values for all existing users.

You can use the linked APIs, and that’s the option most people find first. The step-up flow in the API docs works, but means your app owns the challenge. It has to start it, collect the code, and handle the result. That’s a lot for what is basically “make the user log in again because they are about to do a sensitive thing.”

There’s another way that’s a little different, and it leverages login. Since version 1.60 the authorize endpoint supports the standard OIDC prompt and max_age parameters.

When your app hits a sensitive action, don't call any specific APIs. Instead, it can redirect the user to /oauth2/authorize with prompt=login and/or with a max_age small enough that their existing SSO session doesn’t satisfy it. FusionAuth shows the hosted login page, the user authenticates, and you get a fresh token back. Same code you already wrote for login, with one query parameter added.

Make sure you put the current page/location in the state so you can deliver the customer back to where they were. Here's a video on deep linking.

Using either max_age=0 and prompt=login end up in roughly the same place. I’d use max_age if you want a window like “re-auth if it’s been more than five minutes,” and prompt=login if you want it every time.

A successful redirect doesn’t prove everything. Your app still has to decide whether the token it’s looking at came from a recent authentication.

That’s what the auth_time claim is for. It’s a reserved claim in the JWT body (it moved there in 1.60, and lambdas can’t override it), so your resource server compares it against the clock and rejects beyond your threshold. If it’s too old, send the user back through authorize.

That’s basically the max_age half of RFC 9470, just without FusionAuth issuing the WWW-Authenticate challenge for you. You’d write that 401 yourself.

Caveats:.

This forces a re-login, not necessarily a stronger one. If the user re-authenticates with a password and nothing else, you’ve proven recency and nothing about strength. If you need the second factor on that re-auth, you need MFA to actually fire. A static policy of Required will do it. On Enterprise, the MFA Requirement Lambda can make the decision per request. There’s no acr-style “this was step-up” claim. You get “authenticated at time T,” not “authenticated with a second factor at time T.” If your auditors need the latter, this approach won’t give it to you cleanly, and falling back to the step-up auth API is a better option. It’s a full redirect. For a banking-style “confirm this transfer” flow where bouncing the user to another page is a non-starter, the step-up API approach is still right. This only works when you are using the hosted login pages, not the Login API.

The short version: if sensitive actions are coarse-grained (“view the billing page,” “change the email address”), the redirect approach might work for you. It’s less code, the hosted pages handle the UI, and you’re not maintaining a custom MFA challenge.

But if you need per-operation binding or proof of which factor was used, look at the step-up API.

This behavior occurs when the client sends an Accept-Encoding header that includes compression algorithms, but FusionAuth's response handling doesn't support the requested encoding method in certain configurations.

The solution is to explicitly use Accept-Encoding: identity in your API requests. The identity value indicates that no encoding transformation should be applied, which FusionAuth handles correctly.

If you're using an HTTP client library that automatically adds Accept-Encoding: gzip or similar headers, you should:

Override the default Accept-Encoding header to use identity Or configure your HTTP client to not send compression-related headers automatically

Example:

GET /api/user/search HTTP/1.1 Host: your-fusionauth-instance.com Authorization: <your-api-key> Accept-Encoding: identity

This ensures consistent API responses without encountering 406 errors related to content encoding negotiation.