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.

FusionAuth doesn’t support uploading a CSV to retrieve last-login timestamps. However, you can do this efficiently with the Search for Users API and return lastLoginInstant for many users at once.

How to do it (batch via API)

Use the User Search endpoint
POST /api/user/search (set your X-FusionAuth-TenantId and Authorization headers).

Send an Elasticsearch query using terms to match a batch of emails/usernames, and read lastLoginInstant from each returned user:

{ "search": { "query": "{\"terms\":{\"email\":[\"a@example.com\",\"b@example.com\",\"c@example.com\"]}}", "numberOfResults": 500, "startRow": 0 } } Swap email for username if that’s what you have. If your list is large, chunk it (e.g., 200–500 logins per request) and paginate with startRow / numberOfResults. (Optional) Filter by last-login date with a range query on lastLoginInstant: { "search": { "query": "{\"range\":{\"lastLoginInstant\":{\"gte\":\"2025-10-01T00:00:00Z\"}}}" } }

You can also query by epoch millis if you prefer.

Map results
Each user object includes lastLoginInstant (epoch millis). Convert to your desired timezone/format in your script and write out a CSV.

Tips

If you need all users in a tenant (not just your list), you can search with a wildcard or a match-all query and page through results, then filter locally. For ongoing metrics, consider subscribing to user.login.success webhooks and recording last logins as they happen.

Docs:

Search for Users API (Elasticsearch): https://fusionauth.io/docs/apis/users#elasticsearch-search-engine

You can work around this by passing the IDs directly in your request. Here’s an example of how to structure the request correctly:

from fusionauth.fusionauth_client import FusionAuthClient api_key = 'your-fusionauth-api-key' base_url = 'https://your-fusionauth-instance.com' group_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' user_ids_to_remove = [ 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy', 'zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz' ] client = FusionAuthClient(api_key, base_url) member_delete_request = {'members': {group_id: user_ids_to_remove}} response = client.delete_group_members(member_delete_request) if response.was_successful(): print("Successfully removed users from group!") else: print(f"Error: {response.error_response}")

This approach correctly formats the request for the API to process and delete the specified users from the group.

This issue was addressed in version 1.56.0. Make sure your FusionAuth instance is updated to the latest version, as several reporting-related fixes have been released that resolve this specific problem.

Just an FYI, as of 1.59.0, phone number verification is now fully supported in FusionAuth.

Read more here: https://fusionauth.io/docs/lifecycle/manage-users/verification/gate-accounts-until-user-phone-verified

You cannot integrate Datadog directly into the cloud-hosted version of FusionAuth. The only relevant section in the documentation is "Use Datadog Agent on a Remote Host." This requires setting up Datadog to monitor FusionAuth using the Prometheus Metrics API endpoint. For monitoring failed 2FA rates, FusionAuth does not currently have built-in support. There is no webhook for failed MFA, but you can use the failed login webhook to monitor incorrect password attempts.

Retrieve system metrics using Prometheus
Use the Datadog Agent on a remote host
User login failed webhook

FusionAuth uses standard SMTP for all email connections. As long as Proofpoint Cloud supports a standard SMTP connection where FusionAuth sends transactional emails, initiates a handshake, and completes delivery, the integration will work. You can reference our documentation for details on configuring SMTP with common providers:

Configure Email

You can manage both flows within a single tenant. Typically, you’d configure separate applications, one for the Admin portal tied to your AD/Entra ID provider, and another for your client-facing site using FusionAuth. You can then use login hints or managed domains to direct users to the correct Identity Provider (IdP).

Identity Provider Hints
Managed Domains

Yes, you can create a user without SMTP configured. In the Admin UI, disable the Send Setup Password option and set the password manually during user creation. If you’re using the API, set "sendSetPasswordEmail": false and include a "password" field in the user object.

Users API

During an upgrade, FusionAuth monitors your deployment, and if it becomes unresponsive for more than five minutes, the on-call engineer is alerted. A snapshot of the database is taken before the upgrade, so a rollback is possible, though it is manual and would result in data loss from the time of the upgrade to the rollback. Rollbacks are very rare and have only happened once in the past four years.

You can safely upgrade directly to 1.59, and many customers do skip versions. The upgrade process is straightforward: once started, the deployment status changes to Upgrading and returns to Active when complete. For production instances, downtime is minimal (typically seconds, if at all) because multi-node deployments use rolling upgrades. Most upgrades take under 20 minutes, though in rare cases they can take up to an hour.

FusionAuth never forces you to upgrade, but if you are running a very old version (1–2 years behind) and encounter issues, support may request that you upgrade before troubleshooting.

Upgrading a Deployment

You’ll need to disable or mock CAPTCHA in a test environment and adjust rate-limit settings in FusionAuth’s config or use test API keys to avoid hitting production limits during automated runs.

Good question. I believe this is due to how we implemented our PATCH calls. If you are making a straight API call, you can change the Content-Type header to application/merge-patch+json which will instead overwrite the existing array with whatever you have provided. That's the most straightforward way to replace array values. There are other methods detailed in the doc below but those involve removing values one by one instead of just overwriting them. The downside here is that I don't believe Client Libraries usually support the merge-patch header.

https://fusionauth.io/docs/apis/#the-patch-http-method

If you believe that you have discovered a bug or issue with FusionAuth, please log an issue below.

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

To note, you will likely want to be listening to the registration.update webhook for changes to the registration object prompted by additional fields the user needs to have completed based on what is a required field for self service registration.

In the case of a user entering all these fields "manually" (as part of a registration form) we will create the user and the registration at the same time (thus transmitting all information, including all required registration fields, as part of the user.create and registration.create events).

However, in the case of a social login, the user and registration will be created after the IdP provider returns information via the user.create and registration.create events. Additional registration will be asked of the user as part of the complete registration process (if there are additional required fields) and that additional information will be transmitted as part of the registration.update event.

https://fusionauth.io/docs/extend/events-and-webhooks/events/user-registration-update

The transient policy is not something FusionAuth will support for the SAML NameID policy. From the SAML standards doc, a transient NameID is supposed to be a temporary value which is not a good basis to build a link between two identity systems on. That is the main reason FusionAuth does not support this policy as it would likely lead to issues later down the line with the Identity Provider. Apologies for the inconvenience but having the User ID/UUID shift or change would cause problems as FA relies on a consistent User ID/UUID(NameID) to make a SAML link work.

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Currently, there is not a way to turn it off. Our air gapped license is still going to try to make that call out to us, but that won't cause any issues. The difference being that a normal license would have issues if it could not "phone home" back to us whereas the air gapped license won't have issues but it will still try to make those calls.

If you want to change the font on the hosted login page and the login experience users are offered through FusionAuth, then this can be changed via our Themes. Very likely you will want to update the CSS associated with the theme you are using for the FusionAuth Application/Tenant. Changes to the theme can be completed through this API: https://fusionauth.io/docs/apis/themes/advanced-themes.

Alternatively, you can use the Admin UI to make changes to your CSS as well.

Yes with a Basic Cloud you get one custom domain and no backups, you would just need to update your DNS records to include our CNAMEs for this custom domain. You would submit your custom domain via the Hosting tab of the account.fusionauth.io under the Action Drop down. Then you will be shown the CNAME record for that domain and you will have to update your DNS records to include this CNAME. You can see an example of this at the doc below.

https://fusionauth.io/docs/get-started/run-in-the-cloud/cloud#custom-domains

You would not be able to use your own SSL certificates. We would handle all those in FusionAuth Cloud. We create the certificates on our end and you just need to create DNS records to validate the domain with the CNAME records.

There are a few ways you can get what you need. You can either make these changes via the API and then they will be updated in the UI.

https://fusionauth.io/docs/get-started/core-concepts/users#user-data

https://fusionauth.io/docs/apis/users#update-a-user

Or you can do this using custom admin forms:

https://fusionauth.io/docs/lifecycle/manage-users/admin-forms

The license ID is just the license key itself. You can grab your license here https://account.fusionauth.io/account/plan/. Each license will have a prod key and non-prod key, for testing you just need to grab the non-prod key and use that for your license ID in Kickstart.

https://fusionauth.io/docs/get-started/download-and-install/development/kickstart#set-your-license-id

If you are using the React SDK (which uses Hosted Backend: https://fusionauth.io/docs/apis/hosted-backend, then there are a couple options but they will all require some integration work from your end. The SDKs and Hosted Backend are designed to be easy to use and implement but they are not flexible as you can see with the cookies. Also I'm not sure if this was a consideration in the decision that running FusionAuth locally is not an option but just in case it was: You can use your FusionAuth non-production licenses wherever you want, we do not charge more "per deployment". So you can activate your non-prod license on a locally hosted FusionAuth instance in addition to your FusionAuth on Azure App Service, you can run your non-prod license on as many instances as you want.

Develop your application while hosting it on Azure App service so FusionAuth and the app are on the same domain

Setup a proxy for either your application or FusionAuth so they can be on the same domain

Documentation for setting up a proxy for FusionAuth: https://fusionauth.io/docs/operate/deploy/proxy-setup

Create your own Hosted Backend, example here: https://github.com/FusionAuth/fusionauth-javascript-sdk-express/tree/main

Similar to #3, instead of setting up a Hosted Backend use the OAuth2 endpoints directly. In this scenario you will also be responsible for doing the OAuth code exchange for a token then setting the token cookies on the browser as well as session management with these tokens.

https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/endpoints

https://fusionauth.io/docs/operate/secure/token-storage