@brad sounds super frustrating.

I'll send you a message.

You’re correct—there is no fixed limit on the number of hosted FusionAuth instances you can have.
However, since your account is on invoiced billing, new hosted deployments cannot be created directly through the Account Portal. That functionality is only available for self-serve billing accounts.

Next Steps

• Our Customer Success team will reach out to you via email.
• They’ll help provision the additional non-production instances and add them to your existing order.

Once that’s complete, you’ll have access to the new hosted deployments without needing to manage them through the portal yourself.

I’m reviewing the Hosting page in the FusionAuth Account Portal but don’t see an option to create a new hosted instance.

Based on the documentation and what I’ve found so far, there doesn’t appear to be a hard limit on the number of hosted instances. Is there a different process for creating additional hosted deployments, or is something preventing this option from appearing in the portal?
Ultimately, we’re looking to add at least two additional non-production instances.

Yes, you can mix API clients and end-user logins within the same tenant. Tenant-level controls such as MFA do not prevent this when the authentication flows are properly separated.

Recommended Approach: Use Entities for API Clients

The most common and recommended pattern is to use Entities for API authentication:

• End users authenticate using the Authorization Code grant, which can enforce MFA and other user-facing security requirements.
• API clients authenticate using the Client Credentials grant via Entities.
• Because these are different OAuth grants and flows, tenant-level requirements like MFA apply to users but do not apply to API clients using client credentials.

This allows both authentication types to coexist cleanly within the same tenant while maintaining appropriate security boundaries.

Cost and Licensing

There are no additional licensing or cost implications for using this approach:

• Entities and the Client Credentials flow are included in FusionAuth plans.
• API clients authenticated via Entities do not count as end users for MAU-based billing.

Additional Resources

These resources provide detailed guidance and examples:

• API Authorization with FusionAuth
• Entity Management Concepts
• Using Entities for API Authorization (Video)

This setup is widely used and should cover your use case well.

We are evaluating FusionAuth for JWT-based API authentication and would like to better understand how this fits alongside end-user authentication.

Specifically:

1. Is it possible to authenticate API clients and end users within the same tenant, given that some controls (such as MFA) are configured at the tenant level?
2. If so, what is the recommended approach for structuring API authentication separately from end-user authentication?
3. Are there any licensing or cost implications associated with these approaches (for example, using separate tenants, applications, or service accounts)?

@oliver-muthusami hmmm. I did some poking around Microsoft's documentation and found this.

The inclusion of the refresh token in the response can depend on several factors, including the specific configuration of your application and the scopes requested during the authorization process. If you expect to receive a refresh token in the response but fail to, consider the following factors:

Scope requirements: Ensure that you're requesting the offline_access scopes along with any other necessary scopes.
Authorization grant type: The refresh token is provided when using the authorization code grant type. If your flow differs, the response can be affected.
Client configuration: Check your application's settings in the identity platform. Certain configurations may restrict the issuance of refresh_tokens.

Are you sure you have Entra configured correctly?

@oliver-muthusami Awesome that you got what you need. Thanks for reaching out and letting us know!

@dalamenona This error is coming from Prometheus right? Is there a way to get it to tell you which metric is being reported? If not, could you set up a network monitor and capture the traffic that is being sent to narrow down the metric being sent by FusionAuth that is causing the problem? Maybe then we can look into why FusionAuth is sending the conflicting data.

@oliver-muthusami Have you looked at what Entra ID returns in the reconcile lambda?