osrs-data-hub
XP and gains

Gains per skill

GET
/accounts/{id}/gains

XP gained per skill in a period or an explicit range (stats): every skill the account has, 0 when nothing was gained. Default period=day.

Authorization

bearerAuth
AuthorizationBearer <token>

An API key from the hub’s API keys page.

In: header

Path Parameters

id*string

The account's public id (opaque, base62), as id in /accounts.

Match^[0-9A-Za-z]{1,64}$

Query Parameters

period?string

day = since local midnight in the key creator’s time zone (their hub settings); week/month/year = the last 7/30/365 days. Default day. Not together with from/to.

Value in

  • "day"
  • "week"
  • "month"
  • "year"
from?string

An explicit range instead of period.

Formatdate-time
to?string

With from; default now.

Formatdate-time

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

curl -X GET "https://example.com/accounts/4fT9kQ2mXa7B/gains"
{  "data": {    "account": {      "id": "string",      "name": "string"    },    "period": "day",    "from": "2019-08-24T14:15:22Z",    "to": "2019-08-24T14:15:22Z",    "gains": [      {        "skill": "string",        "xp": 0      }    ]  },  "meta": {    "generated_at": "2019-08-24T14:15:22Z"  }}

XP series of several accounts GET

The same series for several accounts at once, in request order (`stats`): up to 10 accounts with a user key, 50 with a service key. An account the key can’t read makes the whole request 404, exactly like an unknown id.

Event cursor feed GET

Loot, level-ups, deaths, collection log, diaries, combat tasks and superiors of the accounts whose `events` the key may read, ordered by the order the hub stored them, for the Discord bot and Home Assistant automations. **Cursor semantics.** Start with `cursor=now` (no events, just the current cursor) or without a cursor (the newest `limit` events, default 100, at most 500). Then always pass the previous `meta.next_cursor`: you get the events after it, oldest first, and a new cursor. Fewer than `limit` events means "caught up for now". The cursor always moves forward, also past events your filters leave out, and is unchanged while nothing new has arrived. Cursors are opaque; keep them as strings. The feed only serves events stored at least 10 s ago, so a cursor can never skip an event that is still being committed: expect an event 10–15 s after the hub received it. `occurred_at` is when it happened in game, `received_at` when the hub got it (the plugin may resend events up to ~10 minutes late).