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

Please open a support ticket to obtain more guidance.

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:

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.

When planning load or performance tests against FusionAuth Cloud:

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

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.

Key facts about FusionAuth Cloud outbound IPs:

Complete list: FusionAuth will provide the complete list of outbound IP addresses for your specific deployment. These are the only addresses your deployment will use. Note that IP addresses are not exposed through the user interface—opening a support ticket is the only way to obtain them.

Static addresses: The outbound IP addresses are static and will not change during:

For new FusionAuth Cloud deployments, static IP addresses are already configured. If the IP addresses ever need to change, FusionAuth will notify you in advance.

All outbound traffic: All outbound traffic from your FusionAuth Cloud deployment originates from the same set of IP addresses, including:

You can safely use these IP addresses to configure firewall rules, SMTP server allowlists, and other security restrictions for services that need to accept connections from your FusionAuth Cloud deployment.

Important: The provided IP addresses should only be used to allow outbound traffic through firewalls and network control layers. Do not use them for HTTP/API calls, as they won't respond to such requests. In addition to IP allowlisting, consider using custom headers, TLS transport, and client certificates to further secure outbound traffic.

Since AWS only allows one CloudFront distribution per hostname, and FusionAuth Cloud is implementing CloudFront on their infrastructure, you have two options:

The recommended approach is to remove your custom domain from your CloudFront distribution entirely, as FusionAuth will handle CloudFront configuration as part of their cloud service.

When you configure a custom domain with FusionAuth Cloud, you create a CNAME record pointing from your custom domain to your deployment's durable URL (something like <random-string>.durable.fusionauth.dev). FusionAuth manages the CloudFront distribution and SSL certificates on their infrastructure, so you don't need to maintain your own CloudFront distribution for the custom domain.

The proper DNS setup should be:

This allows FusionAuth to provision and manage the entire CloudFront infrastructure, including SSL certificate validation and renewal, as part of their cloud service.

Note: If you're on a High Availability plan and want to use the Unlimited Custom Domains feature, or if you need assistance with the migration, open a support ticket.

If you identify an issue after performing the upgrade:

The rollback operation typically takes 20 minutes to 2 hours, depending on:

Note that this involves a complete database rollback, so plan for 1-2 hours of downtime.

For production upgrades, FusionAuth can provide:

Before upgrading to 1.69.1:

Does this apply to all applications?

Do you have a logout url configured in the OAuth tab? Does that URL exist?

We need to pass the token in the API header as Authorization: Bearer<token> But what is the process so that I can validate the endpoint with the valid token if the token is invalid or does not have the required roles or scope then I should get 401 else I should be able to access the API successfully.

Once you have a token in your API, you can validate it in two different ways. But it's worth noting that to validate the token, you must validate the signature and then the claims.

First option: use a library to validate the signature. Most languages have options. For java, you can use fusionauth-jwt, the readme has sample code.

Second option: use the validate API. You could use the FusionAuth client library to make this call if you'd like.

The first means you have to pick a library. The second means you have to make a network call.

Either way, after you validate the signature, you need to check the claims (issuer, audience, expiration, custom claims) to make sure they are what you expect.

Here's more about how to consume a JWT.

According to this github issue this is corrected by using docker 20.10.5.

Can you try with a later version of Docker? I think this is due to the Java Docker image, and isn't an issue with FusionAuth.

Firstly, the issue may not have been related to the index or patching, but rather a problem with the user's search query or the way they are interacting with the system.

Alternatively, it could be that the reindex and patching process did not fully resolve the underlying issue, and further investigation or troubleshooting is necessary.

It's also possible that there are other technical or environmental factors at play that are causing the exception to continue occurring. In any case, it may be necessary to consult with technical support or seek out additional resources to diagnose and resolve the issue.

Without it we get the error:

Description inside setRelaxVerificationKeyValidation :

Is it the correct way to validate jwt created using ec in authfusion?

https://github.com/FusionAuth/go-client/issues/48

For smaller deployments, you can expect a 5 to 10 minute timeline. For a setup more aligned with a high-volume system with large CPU and database capacities, you can expect a provisioning time of 20 to 45 minutes.