Yes, you can localize social login buttons, but it requires customizing your theme.

In the Theme Helpers file, locate the macro for each IdP button—for example, the Google button macro (starting around line 409). Change the text like this:

From:

<div class="text">${identityProvider.lookupButtonText(clientId)?trim}</div>

To:

<div class="text">${theme.message('google-login')}</div>

Then, define google-login in your Theme → Messages bundles for each supported language. Repeat the same process for the Apple button macro (starting around line 363).

This allows the social login button text to display localized strings based on the user’s selected language.

This error usually means FusionAuth doesn’t have the public key it needs to verify the JWT signature.

Make sure you’ve imported the public key that Keycloak uses to sign tokens into Settings → Key Master in FusionAuth. Check whether your JWT includes a kid (Key ID) claim. If it does, the key you import into Key Master must have a matching Key ID. You can confirm the Key ID after importing by clicking the view (🔍) icon next to the key.

Once the correct key is imported and matches the kid from the JWT, FusionAuth will be able to verify the token’s signature.

FusionAuth doesn’t currently support setting a default IdP for an application or automatically forcing logins through an IdP. You’re welcome to submit a feature request on our GitHub issues page.

If all your users share the same email domain, you could try Managed Domains to route them to the correct IdP.

Another option is to place a proxy in front of FusionAuth. The proxy could inspect incoming requests and append the idp_hint before forwarding traffic to FusionAuth. You can learn more about using a proxy setup here.

Data transfers between FusionAuth deployments aren’t typically included as a standard service, except in cases where a business is scaling up to a larger deployment. However, since this is a new production setup, we can accommodate a one-time migration for you. The process would result in about 10 minutes of downtime.

Make sure you have a master API key on hand, as certain settings—like SMTP configurations—might need to be updated manually after the transfer. Alternatively, you’re welcome to migrate the configuration manually if you prefer.

For Business hosting, FusionAuth creates daily database snapshots around midnight Mountain Time. Three days’ worth of backups are kept. Additionally, a snapshot is taken before any FusionAuth software upgrade and retained for 30 days. Direct database access isn’t available on hosted deployments, so you can’t create traditional database backups yourself. However, most user and configuration data can be retrieved via the FusionAuth API. Some sensitive data, like password hashes or one-time codes (MFA, email verification, magic links), cannot be extracted. Yes — upgrades from Basic to Business or Business to High Availability are possible. A FusionAuth support team member coordinates the process, which typically takes 60–90 minutes and may involve up to 45 minutes of downtime. New deployments use our updated infrastructure, which offers additional features. Downgrading FusionAuth is technically possible but complex and rare. It requires manual intervention by FusionAuth support and can involve significant effort. Downgrades requested within 30 days of an upgrade are simpler and involve less disruption, but the exact downtime is difficult to estimate. Yes — Basic hosting now supports a single custom domain on the new infrastructure. We can help migrate your deployment to the newer model, enabling you to add a custom domain for easier integration. Yes — it’s possible to change your current hosted URL when migrating to the new infrastructure.

More details on hosting plans and capabilities are available here: https://fusionauth.io/docs/get-started/run-in-the-cloud/

You’re correct — when duplicating a tenant, FusionAuth does not copy the SMTP password. This is by design for security reasons. Passwords are stored securely and aren’t exposed in logs, debug output, or the UI, even with debug logging enabled for email.

Unfortunately, there’s no way to automatically carry over the SMTP password when duplicating tenants, and there aren’t plans to change this behavior.

You’ll need to manually re-enter the SMTP password in the duplicated tenant’s configuration.

First, confirm that the engineer’s environment can reach FusionAuth’s licensing servers. From the server, container, or environment running FusionAuth, run the following cURL command:

curl -vv https://license.fusionauth.io

You should see output indicating a successful TLS handshake and a response from the license server. If there’s a connection issue (timeouts, certificate errors, etc.), that could explain why the license validation is failing.

More details about required network connectivity for licensed FusionAuth installations are here:
Paid Plan System Requirements

Yes, you can enable identity providers for applications using the API.

Here’s how:

Use the specific API endpoint for the identity provider type you’re configuring (SAML, OIDC, etc.).

For example, if you’re enabling a SAML or OIDC provider, you’ll use:

PATCH /api/identity-provider/{identityProviderId}

In your request body, set this field to true:

identityProvider.applicationConfiguration[applicationId].enabled

Documentation links for details and examples:

SAML Identity Provider API OIDC Identity Provider API

The general identity provider API overview is here:
Identity Provider APIs

To show the “change password complete” page instead of continuing the OAuth flow, you’ll need to update your password reset email or SMS templates.

Here’s how to do it:

Go to FusionAuth Admin UI → Customizations → Email Templates (or SMS Templates) and edit or copy the template used for password resets. Find the template assigned to the application under Applications → Edit Application → Email tab. If no template is specified there, the system uses the tenant-level template from Tenant → Edit Tenant → Email tab.

In the default template, you’ll see a line like this:

[#assign url = "http://localhost:9011/password/change/${changePasswordId}?client_id=${(application.oauthConfiguration.clientId)!''}&tenantId=${user.tenantId}" /]

Change it to remove the client_id like so:

[#assign url = "http://localhost:9011/password/change/${changePasswordId}?tenantId=${user.tenantId}" /]

Without the client_id in the URL, FusionAuth won’t attempt to continue the OAuth flow after the password change. Instead, it will show the Change Password Complete hosted page.

If you only want this behavior for a specific application, create a separate template for that app and assign it at the application level.

First, ensure that Debug is enabled in your SMTP settings for the tenant. After enabling it, try sending password reset emails again and then check the Event Logs for any errors or details about why emails aren’t going out.

For more troubleshooting steps, see the FusionAuth SMTP documentation:
Configuring Email in FusionAuth

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.

These challenges are expected because of the security protections in place on FusionAuth Cloud deployments. One option is indeed to self-host FusionAuth, which gives you full control over rate limits and CAPTCHA settings.

Alternatively, you could add your IP address to FusionAuth’s allowlist, which can exempt you from certain rate limits and CAPTCHA checks. Details on this approach and the requirements are documented here:
CAPTCHA and Rate Limits - FusionAuth Cloud

Custom domains are available for Basic Cloud deployments. However, this feature relies on a newer backend infrastructure that we’ve recently rolled out. It sounds like your current deployment is on our legacy infrastructure, which does not support custom domains.

We’d be happy to help you migrate your deployment to the new infrastructure so you can enable custom domains. Please note that this migration would involve 30 to 60 minutes of downtime to complete the transition. Let us know if you’d like to proceed!

If you’ve identified which duplicate accounts need to be removed, FusionAuth provides APIs to help manage this process. For smaller numbers of users, you can use the Delete User API, which allows you to either hard-delete or soft-delete (deactivate) a user account.

Delete a User API

If you’re dealing with many duplicate accounts, the Bulk Delete Users API may be a more efficient option to handle multiple deletions in one request.

Bulk Delete Users API

These APIs can help you clean up your user records and ensure each person has only one account in your FusionAuth system.

You’re correct that the Login Records report in FusionAuth only allows searches for individual users by their unique ID or email address. Unfortunately, it’s not possible to search login records directly by email domain through the UI or built-in report filters.

To achieve what you’re looking for, you’ll need to export the login records using FusionAuth’s Export Login Records API. Once you have the data exported (for example, as a CSV), you can then filter the records offline to identify users from a specific domain who logged in during your desired time frame.

You can read more about exporting login records here:
Export Login Records API

Your understanding is correct: in FusionAuth, a user account must have a password to exist, and the platform requires a password when creating a user. This means there’s currently no way to completely eliminate the password field from a registration form using Custom Registration Forms, nor is there a supported method to bypass the password requirement entirely.

However, there’s a workaround if you’d like to simulate a passwordless experience. Using the Advanced Theme Editor, you can hide and automatically populate the password field on the registration page via JavaScript. This way, users won’t see or interact with the password field, but FusionAuth still receives a valid (though randomly generated) password value behind the scenes. To users, the experience feels passwordless, even though a hidden dummy password exists for each account.

More details about customizing the registration page can be found here:
Advanced Theme Editor Documentation

Yes, FusionAuth offers a feature called Managed Domains that can help implement this type of flow. When you set up Managed Domains under an Identity Provider and enable it for your application, the hosted login page will initially display only an email input field. Based on the user’s email domain, FusionAuth will then either redirect them to the appropriate Identity Provider (such as for employee logins) or continue to the standard username/password login for other users.

You can read more about Managed Domains here:
Managed Domains Documentation

Yes, you can disable the Facebook login and signup button through the FusionAuth dashboard. Navigate to Settings > Identity Providers, then edit the Facebook Identity Provider. At the top of the configuration page, you’ll find an “Enabled” toggle that lets you disable Facebook login globally for all applications. Alternatively, you can disable Facebook login for specific applications by using the application-level toggles at the bottom of the same page.

While the simplest built-in way to verify phone numbers is through two-factor authentication (2FA), it’s understandable if you’re not ready to enable that yet. As an alternative, you can implement phone number verification programmatically using FusionAuth’s webhooks.

When a user registers, FusionAuth can trigger the user.registration.create webhook event (or other user registration events). You could listen for this event and run your own logic to send an SMS verification code via your preferred SMS provider. Once the user verifies the code, you could then mark their phone number as verified in your own system or update user data in FusionAuth as needed.

You can read more about relevant webhooks here:
User Registration Webhook Events

Yes, FusionAuth supports sending bulk emails to users. You can use the Send Email API to send messages to multiple users using a predefined email template. This allows you to communicate updates, such as changes to your IdP, to your entire user base.

For details on how to implement this, see the documentation here:
Send an Email API