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

There isn’t a way to stop FusionAuth from synchronizing the user object when using a generic connector. Even when a third-party system is the “system of record,” FusionAuth still requires a local user record to support its internal workflows and features. If you choose not to migrate users into FusionAuth, your external system must also provide application registrations on the returned user object to ensure proper integration.

Regarding your first question, there’s no way to prevent an error if the user.id changes between logins. The id field in the user object should remain consistent across logins. Changing it will inherently cause issues with how FusionAuth matches and manages user records.

For more detail, see the documentation here:
Using the Generic Connector as the System of Record

At this time, the generic connector in FusionAuth only supports a single error response type:

The connector returns a 404 Not Found in any failure scenario, whether: The user does not exist in the external system, or The user exists but provides invalid credentials.

This design is intentional and exists to prevent user enumeration attacks by not revealing which part of the login process failed.

Because of this security restriction:

You cannot display different error messages on the hosted login page for different connector failure scenarios. There’s no way to pass additional custom data or error context from the generic connector to the hosted templates for display purposes.

You can read more details here:
Generic Connector - Response

No, these exceptions are typically innocuous and indicate that the client closed the connection before FusionAuth could complete writing a response. For example, this can happen when a user navigates away while a page is still loading.

This is a known issue with Twilio’s SMS service. A good approach is to use a dedicated Twilio phone number only for MFA codes, and another number for other notifications so users are less likely to reply with “STOP.” Alternatively, you could switch to other MFA methods like TOTP, using apps such as Google Authenticator or Authy, or use email-based MFA. Keep in mind that once a user sends “STOP,” Twilio blocks all future messages until they opt back in by texting “START.” Educating users not to reply “STOP” to MFA messages is also helpful.