Inconsistent presence information across web API endpoints

Reproduction Steps
Send a POST request (with X-CSRF-Token verification) to with the following body:

  "userIds": [

This bug only appears to occur for certain user IDs - I’ve tested a few here:

User ID Legacy API date Presence API date
998796 2021-07-12T19:45:50.927-05:00 2008-09-06T00:16:31.08Z
2819985011 2022-01-21T14:13:02.307-06:00 2021-08-18T18:01:37.723Z
292222536 2022-01-18T17:32:49.447-06:00 2017-04-24T21:12:41.25Z
13268404 2021-12-01T18:27:58.09-06:00 2010-11-29T21:07:27.29Z
21557 2021-04-21T14:33:35.447-05:00 2007-04-24T15:45:26.153Z

Expected Behavior
The response should accurately represent the user’s presence information and last online date.

Actual Behavior
The following information is returned by the presence endpoint:

  "userPresences": [
      "userPresenceType": 0,
      "lastLocation": "Website",
      "placeId": null,
      "rootPlaceId": null,
      "gameId": null,
      "universeId": null,
      "userId": 998796,
      "lastOnline": "2008-09-06T00:16:31.08Z"

The lastOnline field is identical to their join date, which you can verify by sending a GET request to

  "description": "",
  "created": "2008-09-06T00:16:31.08Z",
  "isBanned": false,
  "externalAppDisplayName": null,
  "id": 998796,
  "name": "Templates",
  "displayName": "Templates"

The Presence API claims that the user has not been online since the exact moment their account was created.

On the other hand, the legacy{userId}/OnlineStatus API endpoint returns what appears to be more accurate information:

  "GameId": null,
  "IsOnline": false,
  "LastLocation": "Creating Baseplate",
  "LastOnline": "2021-07-12T19:45:50.927-05:00",
  "LocationType": 3,
  "PlaceId": 95206881,
  "VisitorId": 998796,
  "PresenceType": 0,
  "UniverseId": null,
  "Visibility": 0

The legacy API claims the user was last online when editing the Baseplate template just last year, but the Presence API which claims the user was last online in 2008.

Use the legacy{userId}/OnlineStatus endpoint rather than the newer presence endpoint. This is not a complete workaround as it only accepts one user ID at once, while the newer API is a multiget request.

Issue Area: Roblox Website
Page URL:
Impact: High
Frequency: Constantly
Date First Experienced: 2021-10-14 00:10:00 (-04:00)


Thanks for the report! A ticket has been filed.


Hello! Has there been any update on this? This bug affects users using my API wrapper library, and we’re trying not to implement legacy endpoints like OnlineStatus, so it’d be great if this could be fixed.

1 Like

This issue gets even more troubling as Roblox plans to sunset the legacy API in favor of the broken, new one.


Thanks for bringing this up. We are looking into this issue internally and will provide an update as soon as we can.


This issue will affect my website as well if it isn’t resolved before the legacy API sunsets. I’m waiting to migrate to this API until the lastOnline data is correct because I don’t want to serve inaccurate data to my users.

However, I’m also worried the legacy API could sunset without warning before this issue is resolved and cause requests for this data to suddenly fail on my live server. Looking forward to an update!


Has there been any progress on a potential fix coming down the pipeline soon? This bug makes it impossible to fully migrate code to use the new web API endpoints before the sunset of in less than 4 months.

Based on this response, they should not proceed with sunsetting and delay the date until there is a replacement for all of the API:

So wouldn’t worry too much about the “4 months” time frame, you should get 1 month after they announce fixing this issue or providing a replacement API.

It has been almost a year since this was reported and this bug still hasn’t been fixed.

As of recently the legacy OnlineStatus endpoint seems to be returning 429 ratelimits with The custom error module does not recognize this error. even more frequently than it used to, preventing us from using this workaround. (Try going to in your browser and refresh a couple times and you should see it breaking)


Seems like we have new endpoint that returns the correct lastOnline date:

The docs:

1 Like