To update or extend a user’s account expiry date, you can use the FusionAuth User API to modify the expiry field. You can either set a new expiration date or set the field to null to remove the expiry entirely.

Here’s an example of a PATCH request to update this field:

curl --request PATCH \ --url https://local.fusionauth.io/api/user/42661043-9ab8-4bb8-8778-85217aa05086 \ --header 'Authorization: TulwCDDOmOtvXAVTsRUI4LfSWlF-Bd78uTnQhgviMQG9a1a3Qn7emwBn' \ --header 'Content-Type: application/json' \ --header 'X-FusionAuth-TenantId: 30665132-6767-6665-3132-323466613934' \ --data '{ "user": { "expiry": null } }'

Explanation:
Replace the URL, user ID, and tenant ID with your instance's values.
Setting "expiry": null removes the expiration date and reactivates the user account.
This should resolve the issue and allow the user to log in again.

Unfortunately, FusionAuth does not support changing a user’s ID after the user has been created.

However, when creating users via API, you can specify a custom user ID at the time of creation. This allows you to control user IDs during the initial setup.

API Reference:

Create a User API

Since the IDs are already assigned, your best option might be to adjust your integration logic or recreate the users with the desired IDs.

Bulk Registration of Existing Users:
FusionAuth does not currently provide a bulk endpoint for creating user registrations. However, you can achieve this by using the Create User Registration API to programmatically register users to app2. This requires iterating through the list of existing users and making an API call for each user to add the new registration. Best Practices for Future Scenarios:
To avoid manual one-time activities like this in the future, consider the following approaches: Enable Self-Service Registration:
If you are using FusionAuth's hosted login pages for user sign-ins, you can enable self-service registration for app2. With this feature, a user will automatically have a registration created for app2 when they attempt to log in for the first time. Programmatic Registration:
Implement a workflow in your onboarding process that ensures users are automatically registered to all relevant applications when they are created or updated in your system. Custom Scripts for Batch Processing:
Write a script to fetch all existing users and register them to any new applications as needed. This can be reused whenever new applications are added to your system.

References:

Create User Registration API Self-Service Registration

These steps should help streamline your workflow and reduce manual intervention for future scenarios.

Bulk Registration of Existing Users:
FusionAuth does not currently provide a bulk endpoint for creating user registrations. However, you can achieve this by using the Create User Registration API to programmatically register users to app2. This requires iterating through the list of existing users and making an API call for each user to add the new registration. Best Practices for Future Scenarios:
To avoid manual one-time activities like this in the future, consider the following approaches: Enable Self-Service Registration:
If you are using FusionAuth's hosted login pages for user sign-ins, you can enable self-service registration for app2. With this feature, a user will automatically have a registration created for app2 when they attempt to log in for the first time. Programmatic Registration:
Implement a workflow in your onboarding process that ensures users are automatically registered to all relevant applications when they are created or updated in your system. Custom Scripts for Batch Processing:
Write a script to fetch all existing users and register them to any new applications as needed. This can be reused whenever new applications are added to your system.

References:

Create User Registration API Self-Service Registration

These steps should help streamline your workflow and reduce manual intervention for future scenarios.

Unfortunately, FusionAuth does not support changing a user’s ID after the user has been created.

However, when creating users via API, you can specify a custom user ID at the time of creation. This allows you to control user IDs during the initial setup.

API Reference:

Create a User API

Since the IDs are already assigned, your best option might be to adjust your integration logic or recreate the users with the desired IDs.

To update or extend a user’s account expiry date, you can use the FusionAuth User API to modify the expiry field. You can either set a new expiration date or set the field to null to remove the expiry entirely.

Here’s an example of a PATCH request to update this field:

curl --request PATCH \ --url https://local.fusionauth.io/api/user/42661043-9ab8-4bb8-8778-85217aa05086 \ --header 'Authorization: TulwCDDOmOtvXAVTsRUI4LfSWlF-Bd78uTnQhgviMQG9a1a3Qn7emwBn' \ --header 'Content-Type: application/json' \ --header 'X-FusionAuth-TenantId: 30665132-6767-6665-3132-323466613934' \ --data '{ "user": { "expiry": null } }'

Explanation:
Replace the URL, user ID, and tenant ID with your instance's values.
Setting "expiry": null removes the expiration date and reactivates the user account.
This should resolve the issue and allow the user to log in again.

An FYI for anyone reading this in the future. The kafka integration does have been revised and include a docker based example.

If you are running docker or some other container system where logs are written to stdout you should utilize whatever tooling exists to capture that output (docker logs or similar solutions).

If you are using a zip file installation or some other installation method which writes log files, you can export the system logs using this API call.

Users using an sdk created by swagger can use OAuth.

FusionAuth supports all of the grants listed there except "Client Credentials" (if that's an important grant to you, please vote on this GitHub issue).

That said, you can log a user in using this API: https://fusionauth.io/docs/v1/tech/apis/login#authenticate-a-user

As mentioned in that document, you can require a FusionAuth API key (information about creating this here: https://fusionauth.io/docs/v1/tech/apis/authentication#manage-api-keys ) which would not be a per user API key. Or you could disable authentication for the /apilogin endpoint:

Authentication may be disabled per Application, see application.loginConfiguration.requireAuthentication in the Application API or navigate to Applications Edit Security in the user interface.
and have users authenticate against that endpoint.

If on the other hand you are asking about application type API keys that are managed by FusionAuth, the short answer is that is not a feature of FusionAuth. Please see this forum post for other options.