Users who have rights to post in the FAQ category.
@andrzej-taramina Usually, when we see 403s on the hosted backend, the root cause ends up being an origin issue.
The endpoint calls need to originate from the same domain the FusionAuth instance lives at
There's some CORS information in this section of the hosted backend docs: https://fusionauth.io/docs/apis/hosted-backend#prerequisites
In reading through this post, one of the first things that jumps to mind for me is that between those versions of FA, DPoP was introduced into both FusionAuth and the SDKs.
When first using DPoP in the SDKs (I did it in React), I ran into 401s for /app/me due to not running the requests with the additional DPoP headers.
Depending on your use case, it might make sense to switch from /app/me to using the userInfo property that comes from the SDK.
import { useFusionAuth } from "@fusionauth/vue-sdk";
const {
userInfo,
} = useFusionAuth();
userInfo has most (maybe all) of what's available on /app/me and is also a more efficient fetch for it.
Hey @sameer-syedmanzur!
If you're on any paid plan, I'd recommend looking at our Generic Messengers.
When the generic messenger is hit, it fires off a request to any HTTP endpoint you want. You can then use any method you need to to get the code to the user or post it back to the API to complete the 2nd factor.
If you're on the Community edition (free version), that's not accessible to you, though.
For solution on the community edition, check out this doc if you haven't read it yet: https://fusionauth.io/docs/lifecycle/authenticate-users/multi-factor-authentication#build-your-own-interface
That's how you set up a custom interface for TOTP. That would be the best-practice way of doing 2fa without smtp on community edition. I haven't done anything TOTP-based for testing, but I'd wager there's a TOTP application with an API that could handle this.
Depending on the use case, it might also make sense to set up something simple with something like MailTrap to do testing via SMTP instead of going through all this. That may be a problem depending on the use case, though
Not as a single feature, but doable with some glue code. FusionAuth has no built-in “inactivity warning” workflow or scheduler for this.
It does give you the pieces: a lastLoginInstant on every user, a user search API, an email send API, and user deactivation. You wire them together with a small scheduled job (cron, Lambda, GitHub Action, etc.) outside FusionAuth.
Set up a daily job that does three things:
If a user logs in during the 5-day window, their lastLoginInstant updates and they drop out of the step 3 query automatically.
Use the User Search API with an Elasticsearch/OpenSearch query on lastLoginInstant (milliseconds since epoch). This needs the Elasticsearch/OpenSearch search engine. The database search engine doesn’t support range queries on this field.
POST /api/user/search
{
"search": {
"numberOfResults": 500,
"query": "{\"bool\":{\"must\":[{\"range\":{\"lastLoginInstant\":{\"lt\":1760000000000}}}],\"must_not\":[{\"term\":{\"data.dormantWarningSent\":true}}]}}"
}
}
Compute the lt value in your job as now - 55 days (so replace 1760000000000). Users who have never logged in won’t have a lastLoginInstant, so decide whether to fall back to insertInstant for them.
You can use FusionAuth to send the email or your own system. If you choose the former, create an email template in Customizations → Email Templates, then call the Send Email API with the matching user IDs:
POST /api/email/send/{emailTemplateId}
{
"userIds": ["<id1>", "<id2>"],
"requestData": {
"daysInactive": 55,
"daysUntilDormant": 5
}
}
Your template body can then use FreeMarker:
Hi ${user.firstName!"there"},
As part of our routine account security measures, we monitor accounts for
inactivity. We haven't detected activity on your account in the last
${daysInactive} days, and it is scheduled to be marked dormant in
${daysUntilDormant} days unless activity is detected.
Log in to keep your account active: https://login.example.com
requestData values are available at the top level of the template, so you can reuse the template if you change the thresholds later.
After a successful send, patch the user to record that they've been notified so you don't send them multiple emails:
PATCH /api/user/{userId}
{
"user": { "data": { "dormantWarningSent": true, "dormantWarningSentAt": 1760000000000 } }
}
The must_not clause in the search query above then skips them. If the user logs in, clear the flag so they can be warned again in the future. A user.login.success webhook receiver that uses the API is a clean place to do that.
As far as what you actually do when the user is marked dormant, you have two options:
DELETE /api/user/{id} (soft delete) sets active=false, which blocks login. To reactivate, call PUT /api/user/{id}?reactivate=true. Deactivation also fires a user.deactivate event that you can consume via webhook to notify downstream systems.user.data.dormant = true and handle it in your app where you might do a step-up or force an account recovery. This is gentler and keeps the account usable after a step-up.For a true “close the account” outcome, deactivate first. Hard-delete (?hardDelete=true) only after a retention period that satisfies your compliance requirements.
Caveats:
lastLoginInstant updates when a user authenticates. Silent token refreshes using an existing refresh token don’t necessarily count as logins, so a user with a long-lived session in your app could look inactive. If that matters, track your own activity timestamp in user.data (updated by your app or a webhook) and query that instead. Test this against your own setup before relying on it.
user.lastLoginInstant is global to the user within a tenant. Each registration also has its own lastLoginInstant (user.registrations[].lastLoginInstant). If “inactive” should mean inactive in a specific application, query on that field and filter by applicationId.
Run the job daily and use a window, not an exact day match, so a missed run doesn’t skip anyone.
Page through search results (startRow) rather than assuming one page covers everyone.
Test with a user whose lastLoginInstant you’ve backdated in a non-production tenant.
Make sure your Send Email API key has only the endpoints it needs (search, send email, patch user, deactivate).
I want to email users after 55 days of inactivity, warn them they’ll be marked dormant in 5 days, and then mark them dormant.
Does FusionAuth do this out of the box?
Hey everyone,
We're making a change to how we handle community support, and we wanted to share the reasoning directly with you.
We're retiring support from the #general community Slack channel and making this forum the official home for community support. Starting 10/30/2026, all community questions and peer support will live here.
Why the change?
Slack conversations disappear and be difficult to search. A great answer given to one person in a Slack channel helps only that person — and then it's gone. Forums are different. Every question asked and answered here is searchable, permanent, and available to anyone who comes after you with the same problem. That means:
When you ask a question, you're not just helping yourself. You're building a resource for the whole community.
When you answer someone else's question, your expertise lives on and continues to help people long after the conversation ends.
The collective knowledge of this community compounds over time rather than getting lost.
We believe this is genuinely better for everyone here, and we're excited to build something more lasting together.
If you have questions about the transition, feel free to post them right here.
If you are coming over from the #general Slack channel, welcome to the forum.
If you are an existing forum member, please welcome our new members by helping them out with their questions!
You want to use FusionAuth webhooks to push data into your pipelines. I imagine the JSON will differ, so you might need to modify your mapping layer, but we should be able to provide the data you expect.
Here's our general webhook documentation.
Some events you might be interested in:
Where possible, avoid transactional webhooks because you're using this for analytics and transactional webhooks impact workflow duration negatively.
You can also use the Search API to get adhoc counts/true things up, but it won't necessarily have the richness of data of the webhooks.
@damien For information on releases, please be sure to check out the release-notes. While it may not list which versions the issues were introduced in, it is recommended to stay on the latest version to avoid potential issues.
Our data team has enjoyed lots of data points and insights from our existing auth solution. Specifically around users, data like:
We have data pipelines set up to ingest and turn this data into meaningful insights for the business.
We want to make sure we maintain these important insights. How can we do this?
Hiya @florent-bossuyt ,
Thanks for using FusionAuth.
The upgrade to 1.59.0 added support for phone number as a first class identity. While I don't know for sure, it is possible that impacted lastLoginInstant. I'm not aware of any bug filed.
It's also possible you can find the data previously in the lastLoginInstant in the user.identities[x].lastLoginInstant value, available when you retrieve a user.
Since this is not a known issue, there's no documented procedure for reconciling the data, unfortunately.
Here's one approach, though.
If you have a database backup of the 1.57.0 release, you could stand up a FusionAuth instance pointing to that, and find all the users with a lastLoginInstant that is not null (set A). You'd then run the same query against your prod instance (set B). Then find the folks in set A who are not in set B (call them set C). Set C are the people you need to update.
Unfortunately, you can't update their lastLoginInstant directly. But you can fake a login using the passwordless APIs, which should set it. That is outlined here.
So you'd want to perform that for all the users in set C.
Hope that helps.