However, the easiest way to make sure an application cannot be logged into is to deactivate the application.

How this would work:

Now, your admin user can create a user with a minimal amount of data (perhaps just an email address).

The user will, at first login, be prompted to fill out their profile data, including all fields you've marked required.

This is not full progressive registration, but can be useful in certain circumstances.

Recommended Approach: Use Entities for API Clients

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

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:

Additional Resources

These resources provide detailed guidance and examples:

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

I did this a few weeks ago, so am writing these instructions from memory.

Prerequisites:

Steps:

Separating partners into a different tenant or application can improve security and simplify management. Different tenants fully isolate users and tokens, but would require duplicating application configs. Alternatively, you could keep partners in the same tenant and distinguish them via roles, claims, or separate applications.

If partners are accessing APIs server-to-server, the client credentials grant (Entities in FusionAuth) is the correct choice. Be sure to carefully scope each partner’s access to avoid over-permissioning.

More on these topics:

By default, the email verification flow breaks the OAuth/PKCE context because the user leaves the registration page to check their email and clicks a verification link. FusionAuth can’t continue the OAuth flow automatically from that email link, which is why your hard-coded redirect URI fails without the required OAuth code.

A better solution is to switch your email verification strategy from Clickable Link to Form Field (under Tenant → Email → Email Verification → Verification Strategy). With this approach, users stay on the original registration page, enter the verification code from their email, and the OAuth/PKCE flow remains intact—including the authorization code. This enables seamless redirecting back into your app after verification.

If you’re creating and registering users for an application at the same time, remember to also check the app-level registration verification settings under:
FusionAuth Admin UI → Applications → Edit Application → Registration tab.

More details are in the docs: Registration Email Verification

However, there’s a workaround if you’d like to simulate a passwordless experience. Using the Advanced Theme Editor, you can hide and automatically populate the password field on the registration page via JavaScript. This way, users won’t see or interact with the password field, but FusionAuth still receives a valid (though randomly generated) password value behind the scenes. To users, the experience feels passwordless, even though a hidden dummy password exists for each account.

More details about customizing the registration page can be found here:
Advanced Theme Editor Documentation

Regarding your first question, there’s no way to prevent an error if the user.id changes between logins. The id field in the user object should remain consistent across logins. Changing it will inherently cause issues with how FusionAuth matches and manages user records.

For more detail, see the documentation here:
Using the Generic Connector as the System of Record

This design is intentional and exists to prevent user enumeration attacks by not revealing which part of the login process failed.

Because of this security restriction:

You can read more details here:
Generic Connector - Response

By combining these approaches, you can enhance the security of your FusionAuth deployment and mitigate unauthorized access.

For additional guidance, you can refer to the JWT Populate Lambda documentation, which includes a helpful video walkthrough of the process.

Steps to Set Up:

Resources for Reference:

This approach allows you to track account verification events seamlessly.

Steps to Personalize the Setup Password Email:

Documentation for Reference:

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.

Key Standards:

Replay Resistance Considerations:

Events That Count as a "Login":

For more details, refer to:
What Makes a User Active?

For more details, refer to:

If immediate read-only access is required, consider:

Summary

If immediate read-only access is required, consider:

Summary

Currently our suggestion is to use Javascript on the Login page to jam the claim into a meta field that is shown on a Webhook payload, like jamming stuff into event.info.deviceDescription .

Then you create user.login.success webhook, making sure it is transactional. On login, the event is fired that off to your system and then you extract the claim off the event.info.deviceDescription field and make a PATCH call to FusionAuth. In that PATCH call, you add this to a field on user.data.x.

Then once that PATCH is successful, the 200 response back to the user.login.success event which completes the login and triggers the JWT populate lambda. That lambda extracts the claim off the user.data.x field and puts it into the JWT.

It's not pretty but it is the only way to have this work for now. (For self-service registration you can use a custom hidden field, much easier.)

Relevant docs: