Topics created by FASupportBot

The Helm chart for FusionAuth 1.53.4 has been released and should now be available in the FusionAuth charts repository.

In the meantime, if you need to deploy a specific FusionAuth version before the corresponding Helm chart is released, you can override the image tag in your Helm values file:

image: tag: "1.53.4"

This allows you to use the latest Helm chart while specifying the exact FusionAuth Docker image version you need.

Related Documentation Deploy with Kubernetes - Helm Chart Configuration - Complete guide on configuring and deploying FusionAuth using Helm charts Deploy FusionAuth to the Cluster - Instructions for installing and verifying your Helm deployment Kubernetes Overview - Overview of FusionAuth on Kubernetes with architecture diagrams Upgrade FusionAuth - General guidance on upgrading FusionAuth installations

When you override the image tag in your values.yaml file, you can verify the correct version is deployed by checking the IMAGES column in your Kubernetes deployment:

kubectl get deployments -o wide

The rate limiting you're encountering is applied at the WAF (Web Application Firewall) level on FusionAuth Cloud, not from the FusionAuth application itself. These rate limits protect customers and are standard across all FusionAuth Cloud deployments.

Rate Limit Configuration

FusionAuth does not publish rate limits publicly and they are subject to change.

Please open a support ticket to obtain more guidance.

Whitelisting for Performance Testing

Since these are network-level rate limits, they cannot be configured within your deployment. However, IP allow listing is available to bypass rate limiting for performance testing if your IP address meets these requirements:

It is static It is owned by your company (not shared infrastructure like a CDN) It is associated with a production server (not a developer's laptop)

If you can provide a static IP address that meets these criteria, you can open a support ticket to get it allow listed. Note that allow list changes typically take two to three business days to implement.

Best Practices for Performance Testing

When planning load or performance tests against FusionAuth Cloud:

Open a support ticket before testing to notify the FusionAuth team of your planned stress test window Don't use Basic cloud deployments for performance testing, as they run on limited infrastructure and results won't be representative. Use a Business or High-Availability plan instead, which you can spin up, test, and tear down as needed Implement exponential backoff when you receive a 429 response - this is the recommended approach for handling rate limits gracefully Distribute requests over time rather than sending bursts of traffic Alternative Testing Approaches

If you cannot obtain an allow-listable static IP address (such as for developer machines or CI/CD pipelines), consider:

Running a self-hosted FusionAuth instance for automated testing, which gives you full control over rate limiting configuration Using smaller-scale testing that stays under the rate limits Related Documentation FusionAuth Cloud - CAPTCHA and Rate Limits FusionAuth Cloud - Load Testing Troubleshooting FusionAuth Cloud API Calls User Search API Documentation Advanced Threat Detection - Customizable Rate Limiting (for application-level rate limits within FusionAuth)

The postMethod variable can be null or missing in certain scenarios (such as when a verification link is clicked multiple times), causing the FreeMarker template to fail.

To fix this, you need to provide a safe fallback for the postMethod variable. Update line 16 in your registration/verify.ftl template from:

[#if verificationId?? && postMethod]

To:

[#if verificationId?? && (postMethod!false)]

The !false syntax provides a default value of false when postMethod is null or missing, preventing the FreeMarker exception.

Steps to apply the fix:

Navigate to Customizations → Themes in the FusionAuth admin UI Edit your theme Locate the registration/verify.ftl template Update the conditional check as shown above Save the theme

This pattern can be applied to other templates where variables might be null or missing in certain execution paths.

Why this happens:

According to the FusionAuth documentation, the postMethod variable is not a standard template-specific variable for the /registration/verify template. It is typically available on other verification templates like /email/verify (where it defaults to true). The registration verify template is rendered when a user clicks the URL from the verification email and the verificationId has expired or is invalid. In these scenarios, postMethod may not be set in the template context, which causes the FreeMarker error when attempting to evaluate it as a boolean.

Related Documentation Theme Template Variables - Verify Registration - Documents the variables available in the registration verify template Theme Template Variables - Email Verification - Shows that postMethod is documented for email verification but not registration verification Theme Template Variables - Complete reference for all template variables across different templates

This issue was caused by a bug that existed prior to version 1.68.0. In earlier versions, there was a problem where LDAP connectors scoped to specific domains could incorrectly be called (or not called) for users outside those domains. This could result in the connector appearing to stop functioning entirely after an upgrade.

Solution:

Recreate the LDAP connector configuration. When doing so, verify the Domains field:

If you need the connector to apply to all users, use a wildcard (*) for the domains. If you need domain-specific scoping, explicitly configure the same domains you had previously.

This bug was fixed in FusionAuth 1.68.0. See the release notes for details:

Fixed an issue where Connectors configured for a specific domain in a Tenant could be called for users outside of that domain.

If you encounter this issue after upgrading to 1.68.0 or later and recreating the connector does not resolve it, verify:

Debug mode is enabled for both the connector and the reconcile lambda. The LDAP server is reachable from the FusionAuth instance. Event log and system log (fusionauth-app.log) for any connection or authentication errors.

The user.login.suspicious webhook event requires the Client Risk Configuration to be enabled at the tenant level. Even though Risk Signals are evaluated by default, the webhook event itself won't fire unless this configuration is explicitly turned on.

To enable it:

Navigate to Tenants → Select your tenant → Edit → Security tab Find the Client Risk Configuration section Ensure it's enabled for your tenant

Additionally, verify that the user.login.suspicious event is enabled in the tenant's webhook settings:

Go to Tenants → Select your tenant → Edit → Webhooks tab Confirm user.login.suspicious is checked/enabled

Once both are configured, your webhook should start receiving user.login.suspicious events along with details about which Risk Signals triggered the suspicious login determination.

About Risk Signals and Email Volume

If you're seeing a significant increase in suspicious login emails after upgrading to 1.68.0 or later, this is because FusionAuth introduced comprehensive Risk Signals in version 1.68.0. Previously, only Impossible Travel was tracked. Now additional signals are evaluated including:

Untrusted Device Unrecognized Device Recent Password Change Recent Identity Change Dormant Password Suspicious Agent

All Risk Signals are enabled by default without any configuration changes.

Managing Email Volume

You can tune which Risk Signals trigger suspicious login alerts:

Go to Tenants → Select tenant → Edit → Security tab → Client Risk Configuration Disable specific Risk Signals that are generating too many false positives for your use case Monitoring Without Sending Emails

You can monitor webhook events while tuning your Risk Signals without sending emails to users:

Go to your tenant/application settings → Identities tab Change the Suspicious Login template to "No Template Selected" Monitor your webhook endpoint to see which Risk Signals are triggering Fine-tune your Risk Signal configuration Re-enable the email template once you're satisfied with the detection accuracy

The webhook fires whenever a Risk Signal threshold is met, independent of whether an email template is configured. This allows you to observe and tune the system before alerting end users.

Yes, you need to create two separate applications within the same tenant in FusionAuth. Here's how to configure this:

Configuration Steps

Create both applications in the same tenant - Users are scoped at the tenant level, so applications in the same tenant can share authentication state through FusionAuth's SSO session.

Enable self-service registration on the second application - This ensures a seamless login experience. When a user navigates to the second application while already authenticated to the first, they will be automatically registered and logged in.

How It Works User logs into the first application at your registration URL to create their account. Make sure the rememberDevice parameter is true or checked. You can modify your theme to hardcode that value. While that session is valid, they navigate to the second application's login URL They are automatically registered and authenticated to the second application without manual intervention

The key to this working is that FusionAuth creates an SSO session at the tenant level when a user logs in and rememberDevice is checked. When the authenticated user tries to access the second application, FusionAuth recognizes the existing SSO session and automatically creates a registration for that user in the second application (when self-service registration is enabled).

Password Reset Behavior

Because users are scoped at the tenant level, a password reset applies to all applications under that tenant. Users can utilize the password reset page for the first application and will be able to log in at the second application with the new password.

Sharing Templates

Both applications can share the same theme and templates. Themes are assigned at the tenant level (though you can also assign application-specific themes if needed starting with FusionAuth 1.27+). This means you can configure one set of templates - including password reset, login, and user management pages - that will be used by both applications.

Pre-creating User Accounts

If you create user accounts ahead of time, you can automatically include the registration for the second application when creating the users. This would mean adding that application to their registrations when you create the account initially using the Create a User and Registration API.

Related Documentation Implementing Single Sign-On - Complete guide to configuring SSO between applications Self-Service Registration - How automatic registration works when SSO is enabled Create a User Registration API - Programmatically register existing users to additional applications Application Themes - Configure application-specific themes if needed Themes Documentation - Customize and share login pages and templates across applications

FusionAuth tenants provide logical isolation, not physical isolation. While users, applications, groups, and configuration are logically separated per tenant, all tenants in an instance share the same FusionAuth nodes, database, and search index.

This means that while importing data into one tenant will not impact the data integrity in another tenant, it does draw on the same compute and database capacity that other tenants' logins and profile updates use. Large imports can potentially affect performance across all tenants.

Recommendations to minimize impact:

Serialize imports: Do not run multiple imports simultaneously. Even when migrating multiple clients, avoid having two clients in the initial import phase at the same time.

Pre-hash passwords: Since you're already sending passwords with hash, salt, factor, and encryption scheme, this will significantly reduce load during imports. If passwords were sent as plaintext, FusionAuth would need to hash each one on import (which can take several hundred milliseconds per user).

Start with smaller batches: Rather than immediately using 100k user batches, start smaller to monitor system performance during imports. If performance is acceptable, gradually increase the batch size until you find the right balance between performance and import speed.

Avoid transactional webhooks: You mentioned using Kafka integration instead of custom webhooks, which is good. Ensure you are only using the Kafka integration for events and not using any transactional webhooks, as these can add additional load during imports. Transactional webhooks block the operation until the webhook completes, which can significantly slow down bulk imports. Non-transactional events (like those sent to Kafka) are fire-and-forget and don't block the import process.

Limit concurrent operations: You mentioned planning to run only one import call at a time from one worker, which is the right approach. Updates using the PATCH endpoint can occur in parallel as they should be infrequent.

Monitor database performance: Keep an eye on your database connection pool and query performance during imports. The shared database is typically the bottleneck in multi-tenant scenarios under heavy load.

By following these practices, you can minimize the impact of bulk imports on other tenants in your multi-tenant FusionAuth deployment.

Related Documentation Multi-tenancy Guide - Overview of FusionAuth's multi-tenant architecture and concepts Levels of Isolation - Explanation of logical vs. physical isolation in FusionAuth Import Users API - API documentation for bulk user imports Password Hashes - Details on importing pre-hashed passwords to improve performance Transactional vs. Non-Transactional Events - Understanding event types and their performance impact Kafka Integration - Using Kafka for non-blocking event processing Scaling Your Auth - Best Practices - Performance and scaling considerations for authentication systems

At this time, FusionAuth Cloud does not support customizing HTTP security headers on individual tenant deployments. There is an existing GitHub feature request tracking this capability, but it is not currently on the roadmap and no ETA is available for when this might be added.

If you are running a self-hosted FusionAuth instance, you can configure these headers using a reverse proxy (nginx, Apache, etc.) in front of FusionAuth. For FusionAuth Cloud customers, this configuration is managed at the infrastructure level and cannot be modified per-tenant.

You may want to subscribe to or comment on the relevant GitHub issue to track progress on this feature request.

This is a known bug in FusionAuth 1.69.x that affects the System Logs page when viewing logs from multiple nodes in a cluster.

The issue has been confirmed and logged with the FusionAuth development team. The 401 errors occur when the UI attempts to fetch log content from other nodes in the cluster, causing the tab-switching functionality to fail intermittently.

Unfortunately, there is no workaround available at this time. The bug will be addressed in a future release.

As a temporary measure, you may need to:

Refresh the page multiple times when checking logs across nodes Navigate away from and back to the System Logs page to trigger a reload Access logs directly from individual nodes if you have that capability in your deployment

Once this issue is resolved in a future version, the System Logs page should reliably display logs from all nodes without authentication errors.

FusionAuth does not have a direct passthrough option to prevent storing user data from social login providers. However, there are several approaches to handle this:

Option 1: Use a Reconcile Lambda (Recommended for Social Login)

For social login providers like Google, you can use a reconcile lambda to intentionally overwrite the user data with placeholder values before it's permanently stored:

function reconcile(user, registration, idToken) { // The idToken is the response from the tokeninfo endpoint // https://developers.google.com/identity/sign-in/web/backend-auth#calling-the-tokeninfo-endpoint user.firstName = "Purposely not set"; user.lastName = "Purposely not set"; user.fullName = "Purposely not set"; user.imageUrl = "http://www.notset.com"; }

This ensures that personal data from the social provider is replaced immediately during the reconciliation process.

Option 2: Minimal Registration Form

For new user registrations (non-social), configure your registration form to collect only email and password, avoiding the collection of first/last name entirely.

Option 3: Use Webhooks to Clear Data

Implement a user.create.complete webhook that listens for new user creation events, then use the FusionAuth User API to clear the personal data fields and move them to your profile service. Note that this approach means user data will briefly exist in FusionAuth before being cleared.

Option 4: Lambda with External Fetch (Advanced)

You could use lambdas with fetch calls to move data to your profile service and set FusionAuth fields to null. However, this introduces latency due to network calls during authentication flows.

For Existing Users

If you already have users with stored data, use the User API to programmatically clear the values for all existing users.

This behavior occurs when the client sends an Accept-Encoding header that includes compression algorithms, but FusionAuth's response handling doesn't support the requested encoding method in certain configurations.

The solution is to explicitly use Accept-Encoding: identity in your API requests. The identity value indicates that no encoding transformation should be applied, which FusionAuth handles correctly.

If you're using an HTTP client library that automatically adds Accept-Encoding: gzip or similar headers, you should:

Override the default Accept-Encoding header to use identity Or configure your HTTP client to not send compression-related headers automatically

Example:

GET /api/user/search HTTP/1.1 Host: your-fusionauth-instance.com Authorization: <your-api-key> Accept-Encoding: identity

This ensures consistent API responses without encountering 406 errors related to content encoding negotiation.

You can avoid the fresh local install by pulling the theme files directly from the fusionauth-theme-history repository:

github.com/FusionAuth/fusionauth-theme-history/tree/main

To use this with the theme-helper repo:

Download your current customized theme using download.sh from the theme-helper repo Grab the new target version's theme files from fusionauth-theme-history Run diff-themes.sh from theme-helper against the two folders to see what changed

This approach lets you diff your customized theme against the base theme for any FusionAuth version without needing to spin up a local FusionAuth instance.

Alternative approaches:

If you prefer working directly with git, you can clone the theme-history repo and use git's built-in diffing. For example, to generate a patch between two versions:

git format-patch 1.61.0..1.64.1 --stdout > update-themes.patch

Then apply it to your theme repository:

git am --3way update-themes.patch

You can also use GitHub's built-in diff viewer to compare themes across versions directly in your browser.

Related Documentation Upgrade an Advanced Theme - Complete guide for upgrading custom themes Theme History Repository - Official documentation on using the fusionauth-theme-history repo (available back to version 1.23.0) Theme Helper - Documentation for the fusionauth-theme-helper tool Advanced Theme Upgrade Notes - Version-specific upgrade requirements and breaking changes Themes API - API reference for programmatically retrieving theme files

FusionAuth 1.69.0 introduced changes to how Apple identity provider keys are handled. If your Apple identity provider was configured before upgrading to 1.69.0, you may need to update the key configuration.

To resolve this issue:

Review the 1.69.0 migration guide for specific details about Apple identity provider key changes Navigate to your Apple identity provider configuration in the FusionAuth admin UI Verify that the signing key is properly configured and valid If needed, re-import or reconfigure the Apple private key used for the identity provider Test the Sign in with Apple flow after making these changes

The migration guide contains detailed steps for addressing key-related issues introduced in this version.

When submitting a custom password hasher plugin (or any plugin JAR) for installation on FusionAuth Cloud, you should:

Open a support ticket through the account portal as normal (text-only is fine) Reply to the ticket conversation in Slack with the plugin JAR file attached

The account portal does not accept file attachments during ticket creation, but replying via Slack to an open ticket thread allows you to send files directly to the support team.

Note: Some file-sharing platforms (like Slack) may block .jar files for security reasons. If this happens, you can zip the JAR file first and attach the .zip instead.

Installation considerations

When requesting plugin installation, be sure to specify:

Which specific Cloud deployments/tenants need the plugin installed Whether users are actively logging in (there may be 1-2 minutes of downtime during deployment) Your preferred time window for the installation if downtime is a concern Any considerations for dev/test environments if you have ongoing testing

The support team will handle uploading and rolling the deployment with the new plugin.

This MessagingException: Exception reading response error is often related to network issues or SMTP timeout configuration. Here's how to address it:

Check and Adjust SMTP Timeout Settings

The default SMTP timeout in FusionAuth is 2 seconds, which may be too short if your SMTP provider experiences occasional network slowness. You can increase the timeout by:

Navigate to Tenants > [Your Tenant] > Edit > Email > Advanced In the Additional properties field, add or adjust these configuration values: mail.smtp.timeout=5000 mail.smtp.connectiontimeout=5000

This increases the timeout to 5 seconds. Adjust the value as needed based on your SMTP provider's typical response times. The Additional properties field can contain any Java mail property, and these values will override FusionAuth's defaults.

Email Retry Policy

FusionAuth does not have a built-in retry mechanism for failed email sends. FusionAuth connects directly to your configured SMTP server at the tenant level without using a local mail queue. If an email fails to send due to a connection issue or timeout, FusionAuth will not automatically retry it.

Additional Troubleshooting Steps

Enable SMTP Debug Logging: In your tenant's Email settings, enable the Debug enabled option. This will provide detailed SMTP transaction logs in the FusionAuth event log, which can help identify the root cause of intermittent failures.

Review Event Logs: Check System > Event Log for error events. FusionAuth always creates an event log entry of type "Error" when it cannot send an email.

Send Test Emails: Use the Send test email button in Tenants > [Your Tenant] > Email to verify your SMTP configuration under different conditions.

Implementing Your Own Retry Logic

To handle retries, you can set up a webhook-based solution:

Configure a webhook for the event-log.create event Monitor events delivered to your webhook endpoint When you detect a MessagingException event, trigger an API call to the appropriate endpoint (e.g., /api/user/forgot-password for password reset emails) Important: Implement retry limits in your script to avoid infinite loops with invalid email addresses

This approach gives you full control over retry logic, backoff strategies, and error handling for failed email deliveries.

Related Documentation Configure SMTP - SMTP Settings - Complete SMTP configuration guide Tenants - SMTP Settings Form Fields - Details on the Additional properties field and how to customize Java mail properties Troubleshooting Email - Comprehensive email troubleshooting guide Event Log Create Event - Documentation on the event-log.create webhook event for monitoring errors Start Forgot Password Workflow API - API endpoint for triggering password reset emails programmatically

This error typically indicates a mismatch between the identity provider configuration and the authentication workflow being attempted.

Common causes:

Redirect URI mismatch — The redirect URI configured in your identity provider doesn't match what FusionAuth is sending during the authentication request. The redirect URI in your authentication request must exactly match one of the Authorized Redirect URLs configured in your application's OAuth configuration.

Identity provider type misconfiguration — The identity provider type (SAML v2, OpenID Connect, etc.) may not support the redirect-based flow being used

Missing or incorrect configuration — Required fields in the identity provider configuration may be missing or misconfigured

Wrong login method selected — If you're using the /api/identity-provider/login endpoint, ensure the correct Login Method is configured in the Identity Provider settings

Flow initiated from wrong starting point — The login flow must start at FusionAuth, not directly at the external Identity Provider. Going directly to a third-party IdP URL (e.g., directly to Google or Azure OAuth URLs) bypasses FusionAuth's session handling and will fail.

Resolution steps:

Verify the identity provider configuration in FusionAuth matches your external IdP settings exactly Check that redirect URIs are correctly configured on both sides — navigate to Applications → [Your Application] → OAuth tab and ensure the Authorized Redirect URLs are properly set Confirm the identity provider type supports the authentication flow you're attempting Enable debug mode on the Identity Provider (Settings → Identity Providers → [Your IdP] → Enable debug mode) and review FusionAuth event logs (System → Event Log) for more detailed error information If this started after a recent change, review what was modified in the identity provider configuration Ensure users are starting the login flow from FusionAuth's hosted login pages or proper OAuth authorize endpoint, not bypassing FusionAuth to go directly to the external IdP

If the issue persists, gather the full error details from the FusionAuth event log with debug mode enabled and review your identity provider configuration against the FusionAuth documentation for your specific IdP type.

Related Documentation Troubleshooting Identity Provider Configuration — General troubleshooting guide for IdP issues Add an OpenID Connect Identity Provider — Configuration guide for OIDC IdPs Host a SAML v2 Identity Provider — SAML configuration and troubleshooting Enabling Debugging — How to enable debug mode for detailed error logging Identity Provider APIs — API reference for programmatic IdP configuration

Currently, FusionAuth does not support forcing the register screen when prompt=login is used with an active SSO session. The screen_hint parameter (like Auth0's screen_hint=signup) is not available in FusionAuth.

Workarounds:

Clear the SSO session before registration: You can clear the existing SSO session in your proxy/middleware before redirecting to oauth2/register. While not ideal, this would allow the registration flow to proceed without the passthrough behavior.

Use direct registration without prompt: If you call the registration endpoint without the prompt=login parameter and there are no missing required fields, FusionAuth will complete the registration directly. Only when there are missing fields will users be sent to the complete-registration page.

Feature Request:

If neither workaround meets your needs, this would require a feature request for FusionAuth to support a parameter similar to screen_hint=signup. The product team would need to review this for the roadmap, though implementation timelines would depend on prioritization.

For now, clearing the SSO session before initiating registration is the most reliable approach to ensure users see the registration screen rather than experiencing passthrough behavior.

Related Documentation OAuth prompt Parameter - Details on the prompt=login parameter and its behavior (available since v1.60.0): OIDC Prompt Documentation OAuth Authorize Endpoint - Complete reference for OAuth authorization parameters including prompt, login_hint, and idp_hint: Authorize API Reference Self-Service Registration - Overview of how self-service registration works and how registrations are created: Self-Service Registration Guide Complete Registration - Information on the complete registration flow when missing fields are present (available since v1.65.0): Complete Registration Documentation Logout and Session Management - How to clear SSO sessions programmatically: Logout and Session Management Hosted Backend API - Documentation on the /oauth2/register endpoint behavior: Hosted Backend API

Note: The /oauth2/register endpoint is not fully documented in the official OAuth endpoints reference. There is an open issue to add complete documentation for this endpoint. When a user has an active SSO session and hits /oauth2/register, FusionAuth redirects them through the authorization flow, which causes the passthrough behavior you're experiencing.

For frequent, large-scale user resets in test environments, deleting and recreating the tenant is the recommended approach over bulk user deletion. While there's no "near-instant" bulk deletion method, tenant recreation is significantly faster than iterative bulk deletes at scale.

Key Points About Bulk Delete Delete Users by Query is driven by the search index (specifically Elasticsearch). The queryString parameter has limited support when using the database as the search engine (only simple single-term searches on basic fields like firstName, lastName, fullName, email, and username). CloudFront has a 30-second timeout for origin responses, which explains the 504 errors you're seeing The delete operation likely continues on the FusionAuth side even after CloudFront terminates the connection, making retries risky Recommended Approach: Tenant Delete/Recreate

For test environments with large user populations, follow this workflow:

Cannot delete the Default tenant — the default tenant contains the FusionAuth application and cannot be deleted. Create separate tenants for testing purposes. Delete the test tenant when ready to reset using the admin UI or the Delete Tenant API. This will permanently delete all users, applications, and groups belonging to that tenant. Use docker compose down -v to fully clean the environment Use docker compose up -d to restart Use Kickstart to automatically recreate tenants, applications, and API keys

Kickstart will only run on an empty instance, so the down -v step is necessary. Configure a Kickstart file with your test environment configuration (tenants, applications, API keys) for reproducible deployments.

Note that tenant deletion is an asynchronous operation (as of FusionAuth 1.22), meaning it runs in the background. For very large tenants (2M users), this will still take time but is considerably faster than bulk deleting millions of users through the API.

Note on Import Timeouts

If you're also seeing CloudFront timeouts during large batch imports (e.g., 100k users), the same 30-second CloudFront limit applies. Consider reducing batch sizes when users have multiple registrations, as each registration inserts additional rows into related tables (registrations, application role mappings, etc.), significantly increasing processing time. For best import performance, minimize network hops and consider setting validateDbConstraints to false.

Related Documentation Delete Tenant API - API for permanently deleting a tenant and all its users Bulk Delete Users API - API for deleting users by query, with limitations noted for search engine configuration Kickstart - Declarative tool for quickly replicating environments Clean Up Test Environments - Migration guide with recommendations for test tenant cleanup How to Delete Users After Testing a Migration - Documentation on fastest methods for removing test users Asynchronous Tenant Deletion - Background on how tenant deletion works asynchronously Import Users API - Bulk import API documentation Performance Tips for Migrations - Best practices for importing large numbers of users

Security notices are sent to users in your account.fusionauth.io portal who have been designated as a "Security Officer".

To ensure your team receives security advisories:

Log into account.fusionauth.io Assign the Security Officer role to anyone on your team who should receive security notifications There is no limit to the number of users you can assign this role to

This is documented in the FusionAuth security documentation.

By assigning this role to appropriate team members, you'll ensure that critical security advisories are delivered directly to your organization rather than relying on personal accounts.

You can retrieve all identity provider links for a user by sending a GET request to:

/api/identity-provider/link?userId={userId}

Important: The parameter name is case-sensitive and must be userId (with capital "I"), not userid.

The error you're seeing occurs when the parameter is lowercase userid instead of the correct camelCase userId. Using the correct casing will return a list of all identity provider IDs that the user is currently linked to.

Make sure your request looks like:

GET {baseUrl}/api/identity-provider/link?userId=4aa40fcd-0102-4c26-a51c-9a6c5c0c504a Authorization: <your-api-key>

This endpoint works with a standard API key and will return the identity provider link information you need to determine if a user is linked to external providers.