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.

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.

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 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.

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.

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.

@alex-3 I'm a bit unclear on what you are trying to do.

Can you outline the exact steps you want to take?

HTTP clients, not just Axios, may impose their own requirements for building a valid request or have their own quirks to deal with.

In this case the error can be resolved by providing a Content-Length header with the length of the JSON request data when making the API request via Axios.

If you experience issues with a particular HTTP client, it may be helpful to compare the behavior with another client or check whether there are HTTP headers that may be required by the client.

We managed to figure it out. It was a build error where IntelliJ was not updating the dependency. Thanks for the help.

I tried with all HTTP methods enabled for /api/user only, and it update user successfully.
But if I tried only with GET and PATCH methods enabled for /api/user , I get 'statusCode=401'.
Here is code

import { FusionAuthClient, UserRequest } from '@fusionauth/typescript-client' ... export class FusionAuthService { private fusionAuthClient: FusionAuthClient; constructor(private context: Context) { this.fusionAuthClient = new FusionAuthClient(context.config.fusionAuth.apiKey, context.config.fusionAuth.apiUrl); } ... public async updateUser(userId: string, userRequest: UserRequest ) { return this.fusionAuthClient.updateUser(userId, userRequest) .then(clientResponse => { logger.info("User:", JSON.stringify(clientResponse.response.user, null, 2)); }).catch(logger.error); }

here is invocation of updateUser method that happens on 'user.registration.create' event

if (user) { const patchBody = { user: { email: event.user.email, data: { userId: user.id } }, } await this.fusionAuthService.updateUser(event.user.id, patchBody); }

Now I understand that I use updateUser method and I don't know what kind of HTTP request it used.
I have found patchUser and with it get success.

Thanks for your help.

Hi @casper!

Welcome to the community. This is working as designed. The import API is currently designed to only write new records to the database and not check if the record is already duplicated. This is partly for performance reasons. It maybe be possible to write a script to check existing records, and then only import "new" users based on that feedback, but we do not have any current documented cases of this.

There is an option to get additional information about what is failing on your import.
https://fusionauth.io/docs/v1/tech/apis/users/#import-users

validateDbConstraints [Boolean] OPTIONAL Defaults to false Set this value to true in order to perform additional validation of the request. The import request is intended to be used to populate the initial set of users, this means FusionAuth does not expect to find duplicate users in the database. If a duplicate is encountered a 500 will be returned without this additional validation. If you intend to use this API with existing users in FusionAuth set this value to true to request additional validation be performed on the input request and a 400 response will be returned with JSON body indicating the duplicate values encountered. Setting this value to true will dramatically decrease the performance of this request. If importing large numbers of users in a single request you may need to increase request timeouts to ensure this request does not timeout before it has completed.

I hope this helps,
Josh

We were working on getting it documented and it shipped yesterday. Sorry for the delay!

https://fusionauth.io/docs/v1/tech/apis/entity-management/ outlines all the relevant APIs, including entity CRUD.

You might also be interested in the client credentials grant, one of the main use cases:

configuring entities for the client credentials grant: https://fusionauth.io/docs/v1/tech/oauth/#configure-entities an example client credentials grant: https://fusionauth.io/docs/v1/tech/oauth/#example-client-credentials-grant

You have a few options.

Limit Query One option is to find a way to limit your search by logical increments. For example, if you are searching on users you may consider obtaining and appending results by first name in a loop.

As an example:

for (letter in [a...z]) { query + " AND user email starts with $letter" // do work } Use Version > 1.24.0 when pulling something like users

https://fusionauth.io/docs/v1/tech/apis/users/#request-parameters-12

Request Parameters accurateTotal [Boolean] OPTIONAL Defaults to false AVAILABLE SINCE 1.24.0 Set this value equal to true to receive an accurate hit count on the API response. By default the search engine will limit the hit count to 10,000 users. This means that even if your query may match more than 10,000 users, the returned total count will be 10,000. This is adequate for many use cases such as pagination and general purpose queries. If you are looking for an accurate user count that can exceed 10,000 matches, you will want to set this value equal to true.

Yes.

The only thing you can't create via the API is another API key. You can track that functionality on this issue.

See the tenant documentation for more.

Yes. You can use the tenant API or any of the client libraries to created, read, update and delete tenants and all their configuration.

Version 1.12 is quite an old version. I would recommend upgrading and see if you can recreate the issue.

Double check that you are calling the precise API URL.

http://<hostname>/api/login will work, but http://<hostname>//api/login will not. Though some user agents ignore the double //, FusionAuth treats them as two different URLs, and returns HTML which the API client doesn't know how to parse (hence the error message).

The JWT TTL can be configured per application, so if you were using a different application for OIDC vs an API - then you could do it.

But if you don't want to use multiple applications, then it is not possible, at least currently.

I could see a use case for asking for a JWT with a TTL equal to or less than the configuration and that request being honored, that could be a feature request. But as of right now, the only option is different applications.

These are generated in the UI. So the values are not available from the API.

However you can derive them yourself as well. We just take the URL + /oauth2/authorize?... + redirect_uri etc.