FusionAuth has the following known limits:

User Searches

You cannot filter search results in FusionAuth to only return certain fields. Instead you must do this through post-processing. So if you want to retrieve only the firstName and birthDate fields of a set of users, the results will give you each entire user object and you must select desired fields. You can use the JSON processing facilities in your chosen language to do so, or use a tool such as jq.

Prior to version 1.48.0, when using the Elasticsearch search engine, the maximum number of users returned for any search is 10,000 users. For versions 1.48.0 and later, there is no limit on the number of users which can be returned if you paginate through the results.

There are no latency guarantees around the indexing of user data in Elasticsearch after the user has been updated using the API. The Elasticsearch index is eventually consistent.

The duration between an Update User API call and the changed attributes appearing in a search request would be the time it takes FusionAuth to make the request to Elasticsearch added to the time for Elasticsearch to refresh the index and make it visible to search.

The time it takes to expose index changes to searches in Elasticsearch is called the refresh_interval. This value defaults to one second, so that is the minimum practical delay.

Maximum Users Returned Workarounds

Available since 1.48.0

When using the Elasticsearch engine you can use the nextResults token to page past the 10,000 limit. See Extended Pagination for more information.

You can work around the user search limit by writing one or more search queries to return less than 10,000 users. You can know if the query returns more than that limit by using the accurateTotal request parameter. The User Search API contains more information about the accurateTotal parameter and its effect.

For example, if you needed to download all users, you could query for users with an email address starting with A, then starting with B, and so on. Here’s a sample shell script which retrieves all users using this strategy.

If you have access to the Elasticsearch server, you may also run your query directly against it. The Elasticsearch query result will return Elasticsearch document Ids. Each document Id corresponds to a FusionAuth user Id. To retrieve user data, which is most likely what you are after, use the User Search API with one or more user Ids.

Field Lengths

FusionAuth stores most data in a database. Lengths of specific fields are documented in the database schema for your database type. Please download the database schema for your version of FusionAuth to review length limits for a particular column.

Many varchar columns have a length of 191. Why 191? In MySQL when using a utf8mb4 (4 byte character set) on an indexed column, MySQL limits the usable characters to 191 to account for the overhead of the 4 byte addressing. The InnoDB MySQL engine has a max index length of 767 bytes (for mysql 5.7.9, the earliest version of MySQL which Fusionauth supports). Because we are using utf8mb4 which allows up to 4 bytes per character, we end up with 767/4 ~ 191, so we set the column length to that.

API Keys

FusionAuth is API first and everything can be managed by an API. You can create an API key in the following ways:

Minimum Key Lengths

You can use FusionAuth to manage your cryptographic keys. Due to security considerations, FusionAuth won’t import keys below a certain length.

For RSA keys used to verify signatures, the minimum length is 1024. This key length is allowed as of FusionAuth 1.23.4 and supports external systems that rely upon this weak key length.

For RSA keys used for signing or any other purpose, the minimum length is 2048.

For ECC keys, the minimum length is 256.

See the Keys API for more, including supported algorithms and lengths.

Updating Keys

FusionAuth can manage keys, secrets, and certificates, using Key Master. You can update a Key managed by FusionAuth, with some limits.

Only the name of the Key may be changed; all other fields will remain the same. If you need to update a Key with a new certificate, algorithm or other attributes, please Import a Key.

For example, if you have a Key with an associated expiring certificate, you’ll need to follow the steps similar to those outlined in the JWT signing key rotation documentation:

Note that validation rules will prevent you from removing an in-use key.

Default Configuration

There are a number of items in FusionAuth created by default and which cannot be removed. Additionally, there are sometimes limits to modifying them. These defaults include:

OAuth Logout Behavior

An Application’s OAuth configuration allows you to specify the logout behavior of an application as either “All applications” or “Redirect only.” Specifying the default value of “All applications” will call the configured logout URL for each application in the Tenant except for the FusionAuth admin application.

As of version 1.37, this is no longer a limitation. See the GitHub issue for more information.


IdP Limitations

FusionAuth supports SAML both as a SAML Identity Provider (IdP) and as a Service Provider (SP). The IdP implementation has certain limitations.

Version 2.0 is supported; other SAML versions are unsupported.

FusionAuth supports only the following NameIDPolicy values:

To determine the correct value for NameIDPolicy, please examine the supported values of the software package for which you are configuring FusionAuth as the IdP.

FusionAuth won’t fail validation on any NameIDPolicy value. If the requested NameIDPolicy is persistent, FusionAuth will use that and return the User’s unique id (user.id). In all other cases, the User’s email address (user.email) will be used for the name Id.

Prior to version 1.28.0, FusionAuth supported two NameIDPolicy values, both of which result in user.email being used for the name Id:

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

FusionAuth supports the following SAMLv2 bindings:

Other bindings are not supported.

As of version 1.30.2, if the NameIdFormat is omitted by an SP, urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress will be used.

SP Limitations

FusionAuth supports SAML both as a SAML Identity Provider (IdP) and as a Service Provider (SP). The SP implementation has certain limitations.

Version 2.0 is supported; other SAML versions are unsupported.

FusionAuth supports the following NameID format values by default:

You may also provide your own format name. To determine the correct value, please examine the supported values of the software package for which you are configuring FusionAuth as the SP.

Map between SAML claims and user claims using a reconcile lambda or FusionAuth SAMLv2 Identity Provider configuration.

Prior to version 1.28.0, FusionAuth only supported using the name Id for the user’s email address.

FusionAuth supports the following SAMLv2 bindings:

Other bindings are not supported.


Identifiers (Ids) in FusionAuth are UUIDs.

If you are creating an object, such as an Application, with the FusionAuth API, you can specify this Id, as long as it is a valid UUID. The ability to choose specific Ids exists for Users, Applications, and Tenants, among others, and allows you to avoid breaking external systems dependent on existing identifiers.

Ids cannot be modified after the object is created. If you need to change an identifier, delete the object and recreate it with the correct Id.

User Identifiers

Each account must have an identifier, either an email address or a username. Users may not have multiple email addresses. See this issue for more information.

An account may have both a username and an email address.

Client Ids

OAuth has the concept of a client_id. In FusionAuth, client_ids cannot be modified after creation. As mentioned above, during creation, an Id can be set to any valid, unique UUID value.

The client_id is always the same as either the Application Id or Entity Id, depending on the grant you are using.

Data Type Changes In ‘data’ Fields

FusionAuth provides data fields on many types of objects:

If you are using the Elasticsearch search engine, the user.data, registration.data, and entity.data fields are indexed by Elasticsearch.

For example, you could create a field contained in user.data called migrated and store a boolean value. If you later set that field to an object value for any user, you won’t be able to search for that user. Other users added after this user will be found, however, as long as they have the correct boolean value for user.data.migrated (or no value).

Elasticsearch requires fields to have the same data type across all indexed objects. In the example above, once Elasticsearch “knows” that user.data.migrated is a boolean, it expects this field, if present, to be a boolean for all users.

Therefore, you should not change the data type of fields stored in these fields across entities. This must be enforced by any software that updates these fields. There’s an open GitHub issue to allow FusionAuth to enforce the Elasticsearch schema.

Other object data fields may in the future be indexed by Elasticsearch. Therefore, it is recommended to maintain a consistent schema for all data contained in data fields.

This limitation applies only to installations using the Elasticsearch search engine. However, if you start with the database search engine and eventually need to switch to the Elasticsearch search engine because the database search engine no longer meets your needs, if you have not enforced consistency in the data field types, you will not be able to do so.

Dates that are stored in the data field must be valid. Dates such as “0000-00-00” will fail to parse, for example. Some databases will return that value for invalid timestamps. When setting data values, invalid dates should be set to null to keep the schema valid.

If you do not enforce the schema, objects will be mysteriously hidden from searches. It can also result in a MapperParsingException.

TOTP Algorithm Implementation

While there is underlying support for different code lengths, algorithms and time steps, at the current time the system only allows for the following TOTP settings:

Configuration settingCurrently allowed value

Any attempt to change these configuration values will currently be ignored. If you need different configuration settings, please file a GitHub issue detailing your use case.


The main limits on tenants in FusionAuth are resources of the underlying server. The tenants are lightweight, but do take some resources. There are FusionAuth instances supporting thousands of FusionAuth tenants. At this scale the FusionAuth administrative user interface runs into some issues, so use one of the client libraries to manage the FusionAuth tenant and application configuration. There’s a GitHub issue to resolve these limits in the administrative user interface.

Another current limitation of FusionAuth with respect to tenants is the ability to limit users who log into the administrative user interface to a single tenant. This is not currently supported. There are tracking issues for this functionality. Both GitHub issue #91 and GitHub issue #1524 offer different ways to add support for this feature.

Login records, audit logs and other log files are not separated by tenant. You may be able to query based on FusionAuth tenant or application Ids, but if you need true isolation of log files, you should run separate instances. There’s a GitHub issue to address this.

CORS settings are not configurable by tenant, nor are other settings configured by navigating to Settings -> System.

FusionAuth application objects and other FusionAuth tenant scoped entities cannot be shared across tenants. If you need to keep such entities in sync, you can write scripts to sync up the configuration of multiple FusionAuth applications across tenants. For users, you may be able to have users federate to an external identity provider, and enable that provider for FusionAuth applications across tenants. This will allow your external identity provider to be the system of record for your users.

The default FusionAuth tenant, in which the FusionAuth administrative user interface application resides, cannot be removed.

System Upgrade Downtime

System upgrades require downtime. This is typically on the order of seconds to minutes.

In general, the process for upgrading from version 1.x-1 to version 1.x is:

The recommendation is that you automate the process and minimize downtime. For FusionAuth Cloud we use a configuration management tool and see downtime on the order of seconds for multi-node instances.

You may also, if you are in an environment with a load balancer and creating nodes is easy, follow this process:

There’s an open issue for n-1 version compatibility. Please vote that up if this is important to you.

Database Configuration

Database configuration is limited to a single host. Using a valid JDBC URL with multiple hosts is not currently supported.

There’s a tracking issue to support more database configuration options.

The format of the database username has some limitations as well. In particular, the username cannot contain an @ symbol. Please review the tracking issue for more information.

Password Hashes

There is no FusionAuth API allowing user password hashes to be exported.

If you need to migrate hashes from FusionAuth to any other system, use a database export.


The current SCIM implementation does not support bulk operations using SCIM. Bulk operations on users, such as addition and deletion, are available via FusionAuth APIs, but are not currently supported via SCIM compatible endpoints. If this functionality is required, please file a GitHub issue explaining your use case.

The list operation is limited to 10,000 users if you are using the Elasticsearch search engine. See Limitations for more information.

You cannot create a FusionAuth Registration for a user provisioned with SCIM directly during the provisioning process. See Adding Registrations for workarounds.

While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM client per tenant. While you can have multiple SCIM clients configured to provision users in one FusionAuth tenant, at the end of the day you only have one user data store in each tenant. Conflicts with creation, updates and deletion could happen; they won’t be automatically resolved by FusionAuth. If you need multiple SCIM clients provisioning users into a single tenant, ensure you handle conflicts.

Okay, okay, you want multiple SCIM clients to provision users into a single FusionAuth tenant. Let’s talk about the complexities. Imagine you have an Okta SCIM client provisioning users into a FusionAuth tenant and an Azure AD SCIM client provisioning users into the same tenant.

Issues with this approach include:

Email Templates

There are no FusionAuth enforced limits on the content of HTML or text email templates. You can store whatever HTML or text you’d like.

The only validation performed ensures that non-null strings are provided for each template.

The maximum length of an email template is 65,535 bytes due to the database column used.

Terraform Limitations

You must create an API key either manually or via Kickstart. There is no way to create the initial API key using Terraform.

The Terraform implementation is not currently at parity with the client libraries and the REST API. If you run into any discrepancies that affect your usages, please open a GitHub issue.

What’s Not Limited

All other objects and configuration, including but not limited to the following, are limited only by the resources of your system: