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.

This issue may occur if the Forgot Password email template is still enabled in FusionAuth. To resolve this:

Disable the Forgot Password email template at the tenant level:
Navigate to Tenant > Edit Tenant > Email tab > Template Settings.
Set the Forgot Password template to Feature Disabled.

Check the application-specific settings:
If you have an application-specific template set up, ensure the Forgot Password template is also disabled under the Application settings.

Verify API configuration in the PHP client (if applicable):
If you’re using the PHP client, ensure sendForgotPasswordEmail is explicitly set to "false" (as a string with quotes), not just false (boolean). This ensures the value is passed correctly.
These steps should prevent FusionAuth from sending its own Forgot Password email when the API is called, resolving the double-email issue.

@aponski Have you considered using the apis to change the user password and then directing the flow as you see fit from you own custom pages?

@hareply1 I assume the status field is a custom field? You can use the APIs to query the user and then allow or not allow based on that.

Yes, this can be achieved using the FusionAuth API. Here's how you can implement it:

Set the default password for each user:
Use the POST /api/user/change-password endpoint to set the user's password to the desired format, e.g., company1234. Refer to the "Change a User's Password using an email address or username" section of the FusionAuth documentation. This allows you to update a user's password in a single API call without requiring the Forgot Password flow. Require the user to change their password:
Use the PATCH /api/user/{userId} endpoint to set the passwordChangeRequired field to true. This ensures that the user will be prompted to change their password upon their next login.

API Documentation for reference:

Change a User’s Password Update a User

Optional Customization:
To guide users on the login page to use the default password format, you can customize the messaging through FusionAuth Themes:

Navigate to Simple Theme > Messages > Default. Add a custom message, such as password=Password is company+username, to inform users of the default password structure.

@matt-3 Have you enabled logging in FusionAuth? I would start there to see if there is anything happening internally that is causing the 400 response.

Er9HFQOw3JCfuJHKA1mQ0VnWSp93lyJnRXi4zSN8g

@adam-rahman I heard back from TikTok. Not a very detailed response, but pretty clear they are not going to change anything.

"
Thank you for reaching out to TikTok for Developers Support.

I'm sorry that this can't be changed at present.
"

For now, I will continue to push the issue internally. If there is progress, we will update the Github issue.

No perfect options, but a few workarounds possible

a connector-like proxy which would intercept Client Credentials requests from their customers and use business logic to validate the client secret against the stored Duende hash. stand up a simple proxy in front of the Duende that logs the plaintext client secrets for a period of time before migration (protect these logs of course) go to each client and ask them to use a new FusionAuth specific client secret (analogous to resetting user passwords)

More details on the first option. It requires these steps/prereqs:

FusionAuth Entities Setup The customer should create new FusionAuth Entities that correlate to the Client ID of all APIs and services currently associated with Duende. For now, let FusionAuth generate a random Client Secret. Custom Attribute for Migration: Store a custom attribute such as migration: false on entity.data for all newly created Entities. Migration Steps API/Service Requests Token: The API or service calls Duende's token endpoint. Proxy Interception: The customer's proxy intercepts the client credentials request and searches FusionAuth Entities to find the matching Entity by Client ID. Migration Check: Use an if/else logic to check if migration: false exists for this client ID. If so, the proxy service proceeds with the client credentials request to Duende using the Client ID and Secret (in plain text). JWT Validation: If Duende responds with a JWT, this confirms the Client Secret is correct. The proxy service discards Duende's JWT and then calls the Entity API to update the correct Client Secret and set migration: true on the entity.data object. Complete Migration: The proxy service calls FusionAuth's token endpoint to complete the Client Credentials grant. The proxy service then returns a JWT to the end customer’s API/service, migration is complete.

Which of these make sense depend on how many clients you have, your dev teams bandwidth, and your security posture.

While I have not tested it, this documentation shows how to use an SMTP integration to send an email with resend.

This should work fine with FusionAuth's email settings.

@joshua I believe one reason MFA cannot be supported for non-migrated users is that their details are overwritten with every login.

However, if the source application could retain these details and transmit them through a connector, could it be possible to support MFA?

It's a subtle difference, but one-time use refers to the value of the refresh token, which you use against the /oauth2/token endpoint to get a new access token via the refresh grant.

A sliding window refers to the refresh token itself, which has a unique id which stays the same, even as the value of the refresh token changes.

So if you had a refresh token with a lifetime of 4 hours, a sliding window and one time use configured, you might end up with something like this:

at creation: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value RNhY5yE39t1o2FXKxgyH, lifetime 4 hours when the RT is presented to the /oauth2/token endpoint 3 hours after creation: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value Fh95KZLfSMjMNxpR5B4c, lifetime 4 more hours when the RT is presented to the /oauth2/token endpoint 3 hours later: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value baHneP4s0hBHPEk88GPC, lifetime 4 more hours

More details here: https://github.com/FusionAuth/fusionauth-issues/issues/2925

@mark-robustelli it was my fault, it turned out someone in the team created a lambda operation that was running which changes the user's data as soon as the user signs up which overrides the initial data.

Thanks for your reply though.

Duplicate post

@mark-robustelli Sure,Thanks!
If you find anything please let me know

Here's the PR making the doc better:

https://github.com/FusionAuth/fusionauth-site/pull/3371

@celiaruby127

Also, sorry for my late reply, I saw just now that I had to activate notifications.

@aman-c Have you been able to follow the Next.js quickstart?

Another option that works as of today is to set up a tenant to tenant connector.

Add a connector to the new tenant. Point it at the /api/login endpoint of the old tenant, including an API key as a header.

Change your app to send everyone to a new application in the new tenant.

When the user logs in to the new application, if it is the first time they've been seen, the old tenant data, including password, will be queried. The password hash will be transparently migrated to the new tenant.

This slow migration takes time, but is another option.