Every endpoint. All are GET unless marked otherwise, and none of the GETs change anything. {platform} is one of windows, macos, android. The same list is served as JSON at /api/v1 and as OpenAPI 3.1 at /api/v1/openapi.json — see OpenAPI.

Platforms

Versions

Upcoming

Offsets

Files

Events

Meta

Operator

GET /api/v1/platforms

The whole site in one request. Use this rather than three calls to /version when you want a dashboard.

curl -s https://rbxoffsets.com/api/v1/platforms

{
  "site": "rbxoffsets",
  "platforms": [
    {
      "platform": "windows",
      "label": "Windows",
      "slug": "windows",
      "version": "version-c5aecda2245e4fae",
      "displayVersion": "0.738.0.7381397",
      "releasedAt": "2026-09-09T22:30:28.000Z",
      "upcoming": { "version": "version-0123456789abcdef", "displayVersion": "0.739.0.7390681", "upcomingAt": "2026-09-12T17:09:40.000Z" },
      "storedFiles": 3,
      "offsets": { "supported": true, "versions": 5, "liveTiers": ["verified", "default"], "liveBestTier": "verified" },
      "links": { "page": "https://rbxoffsets.com/windows", "version": "...", "offsets": "...", "upcoming": "..." }
    }
  ]
}

GET /api/v1/{platform}/version

The question this API exists for: what is the current version, and when did it arrive? Cheap — it reads the database and makes no outbound request.

curl -s https://rbxoffsets.com/api/v1/windows/version

{
  "platform": "windows",
  "label": "Windows",
  "version": "version-c5aecda2245e4fae",
  "displayVersion": "0.738.0.7381397",
  "versionCode": null,
  "releasedAt": "2026-09-09T22:30:28.000Z",
  "releasedAtEpochMs": 1788993028000,
  "ageSeconds": 259200,
  "firstSeenAt": "2026-09-09T17:09:40.000Z",
  "previousVersion": "version-e7d81637d42c4b23",
  "upcoming": { "version": "version-0123456789abcdef", "displayVersion": "0.739.0.7390681", "url": "https://rbxoffsets.com/api/v1/windows/upcoming" },
  "installable": true,
  "abis": [],
  "stored": true,
  "download": "https://rbxoffsets.com/download/windows/version-c5aecda2245e4fae",
  "sha256": "9f2c...",
  "sizeBytes": 135843437,
  "offsets": { "supported": true, "versions": 5, "liveTiers": ["verified", "default"], "liveBestTier": "verified", "url": "https://rbxoffsets.com/api/v1/windows/offsets" },
  "checkedAt": "2026-09-12T09:04:00.000Z"
}

GET /api/v1/{platform}/current

Different question, and the important distinction on this page: /version reports what Roblox released; /current reports what you should use.

They usually match. On Android, when the newest release ships no x86_64 artifact they do not, and this endpoint deliberately answers with the newest build that is installable, explaining itself in heldBack. On desktop there is no such ambiguity, so it always answers with production.

It resolves a live download URL, so it is slower and may reach out to upstream. Pass ?url=false for the decision without the URL.

curl -s "https://rbxoffsets.com/api/v1/android/current"

{
  "platform": "android",
  "version": "2.738.1397",
  "displayVersion": "2.738.1397",
  "versionCode": 273491700,
  "kind": "apk",
  "fileName": "roblox-2.738.1397.apk",
  "url": "https://<account>.r2.cloudflarestorage.com/...",
  "urlExpiresAt": 1786554013000,
  "source": "r2",
  "sha256": "9f2c...",
  "sizeBytes": 231014912,
  "abis": ["armeabi-v7a", "arm64-v8a", "x86", "x86_64"],
  "targetAbi": "x86_64",
  "isProduction": false,
  "lifecycle": "future",
  "offsetsTarget": true,
  "heldBack": null,
  "downloadPath": "https://rbxoffsets.com/download/android/2.738.1397"
}

lifecycle

The example above answers "future", and that is not an error — it is the ordinary Android answer for a day or so after a release. It is worth reading carefully, because isProduction: false on its own is ambiguous in a way that has misled people: it is the same value for “staged ahead of the rollout” and “stale”, and on Android the first is routinely true of the build being recommended.

The same field appears on every entry from /api/v1/{platform}/history, alongside recommended, so a client can tell staged builds from historic ones in a single call.

Do not refuse to install a build because lifecycle is "future". If you want to track the rollout rather than the newest usable build, read /version instead — that endpoint reports what Roblox released, and this one reports what to use.

offsetsTarget

Offsets are produced by running the client and reading its memory, which needs an x86_64 container. An arm-only Roblox release cannot produce them — not "has not yet", but cannot, ever — however current it is. So the build offsets belong to is the newest x86_64 build, and offsetsTarget is how you confirm a version is that build.

Why x86_64 and not an ARM ABI. The consumer of the Android builds tracked here is usually not a phone. It is a desktop Linux machine running the Android client through a compatibility runtime, and those runtimes execute the x86_64 library natively — which is also exactly why a dump can be taken from one. An ARM build runs fine on a phone and is genuinely the live Roblox release; it simply cannot be run this way and cannot be dumped. That is the whole reason this site tracks one ABI rather than all of them, and the reason “Roblox released a new Android version” and “there are new Android offsets” are separate events here.

On a day when Roblox is serving an arm-only release, three different versions are in play at once, and it is worth being able to name them apart:

If you are pairing offsets with a version number, read it from offsetsTarget — never from /version. The arm-only release is downloadable here and is genuinely the live Roblox build; it simply has no offsets and never will.

GET /api/v1/{platform}/files

The inventory. Only versions in this list can be downloaded from this server; older ones are pruned as new builds land (5 kept per platform). Offsets are never pruned.

{
  "platform": "windows",
  "count": 2,
  "latest": "version-c5aecda2245e4fae",
  "archiveEnabled": true,
  "retainVersions": 5,
  "files": [
    {
      "platform": "windows",
      "version": "version-c5aecda2245e4fae",
      "displayVersion": "0.734.0.7340917",
      "versionCode": null,
      "kind": "zip",
      "fileName": "RobloxApp.zip",
      "sizeBytes": 133904975,
      "sha256": "9f2c...",
      "storedAt": "2026-08-12T16:09:55.000Z",
      "isProduction": true,
      "isLatest": true,
      "path": "/download/windows/version-c5aecda2245e4fae",
      "url": "https://rbxoffsets.com/download/windows/version-c5aecda2245e4fae",
      "abis": []
    }
  ]
}

GET /api/v1/{platform}/files/{version}

One entry, in the same shape as an element of files. latest is accepted in place of a version. A tracked-but-unstored version answers 404 with a reason saying which kind of "no" it is.

curl -s https://rbxoffsets.com/api/v1/mac/files/latest

On Windows the entry also lists packages — any extra packages from Roblox's manifest that this deployment keeps — each with a /download/windows/{version}/{package} URL.

GET /api/v1/{platform}/history?limit=N

Recent versions, newest first. limit defaults to 10, maximum 50. Each entry carries lifecycle, offsetsTiers, upcomingAt and deployedAt. Desktop history begins when this server first polled — see the note on the contents page.

curl -s "https://rbxoffsets.com/api/v1/windows/history?limit=5"

GET /api/v1/{platform}/builds/{version}

One build's whole record: where it sits, when it appeared, reached the CDN and went live, how long that took (leadSeconds), its stored file, every offsets set with file URLs, and every event recorded against it. latest means the live build.

curl -s https://rbxoffsets.com/api/v1/windows/builds/version-c5aecda2245e4fae

Plain-text answers

For a shell or a batch file with no JSON parser: one line, the build identity, and nothing else.

curl -s https://rbxoffsets.com/api/v1/windows/version.txt    # the live build
curl -s https://rbxoffsets.com/api/v1/windows/upcoming.txt   # the upcoming build; 204 and empty when none

Upcoming, channels and events

/api/v1/{platform}/upcoming, /api/v1/upcoming and /api/v1/{platform}/channels are covered in Upcoming builds; /api/v1/events and the Atom feeds in Events and feeds.

GET /api/v1/windows/manifest/{version}

Roblox's package list for a Windows build — every package, its MD5 and its sizes — parsed. Read from the copy stored beside the build when there is one, and from Roblox otherwise.

curl -s https://rbxoffsets.com/api/v1/windows/manifest/latest

GET /api/v1/{platform}/status

The whole picture for one platform in one object: production, builds in flight, the newest usable build, stored files, and recent events. This is what the platform pages render. Useful for a dashboard; heavier than an updater needs.

GET /api/v1/search?q=TERM&limit=N

What the search control in the top right calls. It searches the site's own pages — each platform, each platform's offsets, the documentation, the policies — and the build ledger, and returns links rather than data. Use it to send somebody to the right page; use the endpoints above to read the facts on it.

curl -s "https://rbxoffsets.com/api/v1/search?q=windows%20offsets"

{
  "query": "windows offsets",
  "results": [
    {
      "title": "Windows Roblox offsets",
      "detail": "Memory offsets for every tracked Windows build",
      "href": "/windows/offsets",
      "kind": "Offsets",
      "url": "https://rbxoffsets.com/windows/offsets"
    }
  ]
}

kind is one of Offsets, Platform, Build, Documentation, Archive or Site. limit defaults to 8 and is capped at 40. A query shorter than two characters returns an empty list rather than everything.

Pages, for a reader rather than a client

Two of these are worth knowing even if you only ever call JSON, because they are what you send a person:

Those pages are generated from the same ledger the API reads, so they cannot disagree with it. Every one of them is listed in https://rbxoffsets.com/sitemap.xml.

GET /healthz

Answers 200 when the poll loop is running and 503 when it has stalled — a dead tracker reports unhealthy rather than cheerfully serving a version number that stopped updating three days ago. Point an uptime monitor here.

{"ok": true, "uptimeSeconds": 84213, "platforms": ["windows","mac","android"], "poll": {"stalled": false},
 "sources": {"weaoFuture": {"ok": true, "checkedAt": "…"}, "deployHistory": {"ok": true, "checkedAt": "…"}, "offsetsListing": {"checkedAt": "…"}}}

sources reports each upstream separately. A healthy loop with a failing source is a tracker that cannot see part of the picture — upcoming builds, say — and this is where that shows.

Operator routes

Everything under /internal/ always requires the token and is covered in Publishing offsets. A client should never call them.