You’re correct: FusionAuth’s Lambda environment does not provide access to external libraries (including AWS SDKs or SigV4 helpers), and there is no secure secrets store available to Lambdas. That means if you need AWS SigV4 signing from inside a Lambda, you would have to implement the signing logic yourself and embed any required credentials directly in the Lambda code—this is generally not considered secure.

Also, if you are using FusionAuth Cloud, you cannot place Lambdas into your private network (for example, the same VPC/network as your API Gateway), so that option isn’t available in hosted deployments.

If you need this capability, the recommended approach is typically to move the signing and secret handling into a system you control (for example, a backend service that FusionAuth calls), rather than performing SigV4 signing directly in a FusionAuth Lambda.

Related issue tracking:
https://github.com/fusionauth/fusionauth-issues/issues/1629

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.

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

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

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

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

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.

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

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.

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

FusionAuth does not currently offer an API specifically for importing roles in bulk. However, roles can be created for an application using the following approaches:

Create a Single Role via API:
Use the POST /api/application/{applicationId}/role endpoint to create roles individually.
Documentation: Create an Application Role Create Multiple Roles During Application Creation:
When creating an application via the POST /api/application endpoint, you can define multiple roles as part of the application configuration. This is the most efficient way to set up multiple roles at once if you are creating a new application.

While there isn’t a dedicated role import API, combining these endpoints allows flexibility in managing roles programmatically.

Monthly Active Users (MAU):
Using the Bulk User Import API will not count against your monthly active users (MAU) quota. This makes it suitable for staging or non-production environments where users are frequently added and removed. User Deletion Performance:
The Bulk Delete API processes users one by one, performing verification checks for each user, which can cause delays. Unfortunately, there is currently no faster or more efficient way to delete users in bulk due to the way the API is designed. Alternative Approach:
While tools like Terraform can automate the process of importing and deleting users, this essentially scripts the same API calls and will still encounter the same deletion delays. However, Terraform may simplify managing the environment by automating repetitive tasks. Documentation: FusionAuth Terraform Integration

If the deletion delays significantly impact your workflow, consider submitting a feature request to FusionAuth for performance improvements in bulk deletion.

The sendSetPasswordEmail functionality currently has a limitation in that it doesn’t allow you to pass custom data for use in the email template through the API. However, you can still achieve personalization by configuring the email template directly in the FusionAuth Admin UI.

Steps to Personalize the Setup Password Email:

Edit the Email Template: Navigate to Customizations > Email Templates > Setup Password in the Admin UI. You can either edit the existing default template or duplicate it to create a new one. Use variables like ${user.firstName!'Unknown User'} or any other user data fields to customize the message. Assign the Template to Your Application: Go to Applications in FusionAuth. Edit your application and assign the appropriate template to the Setup Password field. Consider Custom Message Content: Include static or semi-dynamic content like "You were invited by ABC" in the email template. If you have multiple initiators, you might need to create separate templates for each scenario.

Documentation for Reference:

Email Templates and Replacement Variables FusionAuth Email Templates

While the API does not allow for passing custom fields directly for sendSetPasswordEmail, configuring the templates in the Admin UI should allow you to achieve the desired level of personalization.

You can retrieve this data using FusionAuth's API, which provides specific endpoints for users, entities, and entity grants. The users object includes a registrations section that lists the applications each user is registered with. Here are the relevant API endpoints and documentation:

Users: Search for Users Entities: Search for Entities Entity Grants: Search for Grants

Steps to Retrieve Data:

To fetch all users, entities, or grants, perform a search query with a queryString parameter set to *. Use pagination as described in the API documentation to handle large datasets efficiently.

This approach allows you to systematically acquire the information your data engineers need on a daily basis.

The POST /api/user/change-password endpoint does not support a flag to require a password reset. However, you can achieve this by using the PATCH /api/user/{userId} endpoint and setting the passwordChangeRequired field in the request body.

Here’s an example JSON for the PATCH /api/user/{userId} call:

{ "user": { "passwordChangeRequired": true } }

Alternatively, you can set this requirement manually via the FusionAuth Admin UI:

Navigate to Users > Manage User > Edit User Dropdown. Select Require Password Change.

Documentation for reference:

Update a User

This ensures the user will be prompted to reset their password upon their next login.

There seems to be a misunderstanding regarding the deprecation timeline. The /api/user endpoint itself is not being deprecated at the end of the year; only JWT authentication for that API is being deprecated. You can continue to use the /api/user endpoint by switching to API key-based authentication.

Steps to Continue Using /api/user:

Update your integration to authenticate API calls with an API key instead of JWT. Access data.salutation as usual through the /api/user endpoint. This data is part of the user.data object, which is populated by your integration and not automatically generated by FusionAuth.

Steps to Use /oauth2/userinfo:

Write and install a UserInfo lambda which can read the user.data object and augment the userinfo response to include the data.salutation value. Docs on this lambda.

The initial API key created during setup is primarily intended for administrative use and API access. While it is not directly used within the FusionAuth UI, it can be used to authenticate API requests depending on the permissions granted to it.

Recommendations:

Keep an API Key for Emergency Access: It is advisable to retain at least one API key for break glass reasons—for example, to regain access in case of authentication issues. API Usage: API keys are commonly used to interact with FusionAuth’s REST APIs for various authentication and management tasks.

What Happens If You Delete It?

If no other API keys exist with sufficient permissions, API-based administrative access to FusionAuth will become unavailable. If your system relies on this API key for integrations or automation, those requests will fail.

To avoid disruptions, ensure that you have another valid API key with the necessary permissions before deleting the initial one.

The initial API key created during setup is primarily intended for administrative use and API access. While it is not directly used within the FusionAuth UI, it can be used to authenticate API requests depending on the permissions granted to it.

Recommendations:

Keep an API Key for Emergency Access: It is advisable to retain at least one API key for break glass reasons—for example, to regain access in case of authentication issues. API Usage: API keys are commonly used to interact with FusionAuth’s REST APIs for various authentication and management tasks.

What Happens If You Delete It?

If no other API keys exist with sufficient permissions, API-based administrative access to FusionAuth will become unavailable. If your system relies on this API key for integrations or automation, those requests will fail.

To avoid disruptions, ensure that you have another valid API key with the necessary permissions before deleting the initial one.

There seems to be a misunderstanding regarding the deprecation timeline. The /api/user endpoint itself is not being deprecated at the end of the year; only JWT authentication for that API is being deprecated. You can continue to use the /api/user endpoint by switching to API key-based authentication.

Steps to Continue Using /api/user:

Update your integration to authenticate API calls with an API key instead of JWT. Access data.salutation as usual through the /api/user endpoint. This data is part of the user.data object, which is populated by your integration and not automatically generated by FusionAuth.

Steps to Use /oauth2/userinfo:

Write and install a UserInfo lambda which can read the user.data object and augment the userinfo response to include the data.salutation value. Docs on this lambda.