New Ingame Data Export APIs (PTS)

    Contents [Hide]

    Hello tool developers,


    some new data export endpoints have recently been made available on the PTS server Singularity for testing and feedback.

    Available Endpoints

    Species Bonuses

    /game/index.php?page=componentOnly&component=externaldataexport&action=speciesBonuses&asJson=1

    • Method: GET
    • Response format: JSON

    Account Information

    /game/index.php?page=componentOnly&component=externaldataexport&action=accountInfo&asJson=1

    • Method: GET
    • Response format: JSON

    Technology Quantities

    /game/index.php?page=componentOnly&component=externaldataexport&action=technologyQuantities&asJson=1

    • Method: GET
    • Response format: JSON

    Note: This endpoint returns only the currently active quantities of selected technologies. If a technology is inactive (for example because it is not selected or because population requirements are not met), the returned quantity will be 0.

    Import / Export Information

    /game/index.php?page=componentOnly&component=externaldataexport&action=importExportInfo&asJson=1

    • Method: GET
    • Response format: JSON

    Important

    These endpoints are currently available on Singularity and should be considered Beta. Their structure and contents may change before they are made available on live servers.


    The endpoints are only accessible from within an authenticated game session and cannot be accessed externally without being logged into the account whose data is being requested.

    Feedback & Requests

    Feel free to explore these endpoints and provide feedback on their structure, contents, and usability.


    If there is account data that you currently cannot access, or if you have suggestions for additional endpoints, please post them in this thread. Constructive and technically feasible suggestions can be forwarded for consideration.


    Thank you for helping improve the tooling ecosystem around OGame.

    Hi RiV-, we integrated all four endpoints into our tool (which we will present in the coming days) and tested them thoroughly on Singularity (13.0.0-beta55)

    AI-assisted structured feedback.


    1) Undocumented header + inconsistent error handling

    The endpoints only work with "X-Requested-With: XMLHttpRequest". Error handling

    is then inconsistent, and every case is HTTP 200:

    - missing header -> plain text "An error has occured!"

    - wrong component -> plain text "An error has occured!"

    - wrong/missing action (with header) -> proper structured JSON:

    {"status":"failure","success":false,

    "errors":[{"message":"LOCA_API_ERRORS_INVALID_PARAM","error":100053}]}

    Please (a) document the required header, (b) use real HTTP status codes for

    errors instead of 200, and (c) return the structured JSON error consistently

    (the missing-header and wrong-component paths should not fall back to plain

    text). Today a tool cannot cleanly tell "endpoint unavailable" from

    "malformed request".


    2) technologyQuantities has a session side effect (planet switch)

    It accepts a cp=<planetId> parameter and correctly returns that planet's

    quantities. BUT the call PERSISTENTLY changes the session's selected planet:

    after action=technologyQuantities&cp=A, a subsequent parameterless call

    returns planet A's data (verified with a ship count that differs between two

    planets: cp=P1 -> 24, cp=P2 -> 0, and the next unparameterized read tracks the

    last cp used). So reading another planet silently switches the player's active

    planet. A read-only export endpoint should not mutate game state - please make

    the planet target a side-effect-free per-request parameter.


    3) accountInfo - one genuinely missing field: moon jumpgate cooldown

    accountInfo is exactly what tool devs need (officers, per-planet real hourly

    production, buffs with epoch expiry, siblingId) - thank you. The one gap is the

    moon jumpgate COOLDOWN state: the gate level is already present

    (buildings["43"]), but not the remaining recharge time. That timer is server

    state a tool cannot reconstruct if it wasn't watching when the jump happened

    (tool installed later, jump made from another tab/device); today we compute it

    from the level formula. The buffs array already uses the right pattern

    (buffEnd epoch) - a "jumpgateCooldownEnd" epoch per moon would be perfect.

    (Universe/fleet speeds are absent from accountInfo too, but the values we need

    are already on the page meta tags, so that's not a real gap.)


    4) newAjaxToken - please document (minor)

    Every response, including error responses, includes newAjaxToken. In our tests

    calling the read endpoints did not change the page's ajax token (window.token

    was unchanged and the returned value equalled the current one), so it looks

    harmless. Please confirm/document that these read endpoints are token-neutral,

    or drop the field for read-only calls to remove the ambiguity.


    5) Beta bug: empire standalone JSON "hourly" holds per-SECOND production

    On page=standalone&component=empire, the JSON embedded in the page (passed to

    createImperiumHtml) has production.hourly containing per-second values. On one

    planet production.hourly.metal = 854, while:

    - OGame's own resource-bar tooltip shows "Current production: +3,077,696" (per hour),

    - accountInfo reports production.metal = 3,077,696,

    - and 854 exactly matches resourcesBar.resources.metal.production (854.9/sec).

    So "hourly" is really the per-second rate (854 * 3600 = 3,077,696); daily/weekly

    carry the same mislabeled base (x24 / x7). The empire JSON thus contradicts

    OGame's own UI. On v12 live this field is genuinely hourly, so it looks like a

    beta regression. Note: the empire view doesn't render hourly production in its

    UI, so this is invisible to players and only bites tools consuming the embedded

    JSON - easy to ship to live unnoticed. (Related: on the same page "itemNames"

    now maps item UUIDs to names instead of technology id -> name.)


    6) selectedSpeciesTechnologyIds - please guarantee/document the ordering

    Verified across all 15 of our planets: this array lists the planet's lifeform

    slots IN ORDER - the 12 buildings (1N1xx) first, then the up-to-18 research

    slots (1N2xx), in exactly the same order as the lfresearch page cards, with

    levels available in speciesResearches (0-level slots included). This let us

    replace 15 HTML page fetches with a single call. If the ordering is guaranteed,

    please document it; if it's an implementation detail that may change, we'd like

    to know. Same for units: documenting that speciesBonuses values are FRACTIONS

    (e.g. 0.719 = 71.9%) would prevent a classic off-by-100 in every new tool.

    Thanks for the thorough testing and clear write-up. Going through your points:


    1) Undocumented header + inconsistent error handling

    Noted, I'll forward it. Honest heads-up though: I wouldn't hold my breath on this one. The error handling is likely a deeply nested structural thing rather than something they can cleanly fix for this one endpoint, so a targeted fix here may not be feasible.


    2) technologyQuantities + cp side effect

    This isn't an API bug to fix — it's expected behavior you need to design around. cp stands for "change planet," and it does exactly that: it switches the account's active planet, same as clicking that planet in the sidebar. Using it in a background call to read another planet is not permitted for tools (see the forbidden features list) precisely because it triggers a real state change rather than a read.


    You don't need it anyway: accountInfo already returns per-planet data for all planets in one call, so there's no reason to use cp with technologyQuantities for cross-planet reads.


    3) accountInfo — jumpgate cooldown

    I hear the use case, but I don't think accountInfo is the right place for this, and I'd push back on the underlying approach a bit: accountInfo is a heavy endpoint (it's effectively a full account snapshot) and isn't meant to be polled continuously to keep external state fresh. Doing that repeatedly to "catch" a timer changing:

    • puts unnecessary load on the server for something that's fundamentally an event you either observed or didn't, and
    • refreshes the highscore for everything across all your planets at once, rather than just what a normal single-planet action would trigger — which for an observer is a giveaway that you're online and actively refreshing.

    If a player switches devices/tabs and your tool wasn't running to see the jump happen, that's a gap in what your tool can know — not something the API should compensate for by making every consumer poll a heavy endpoint. A tool is expected to track what happens while it's active, not be omniscient about actions taken elsewhere.


    That said, the actual ask — a cooldown end timestamp — is reasonable on its own merits, just not via accountInfo. A good fit would be an inline data attribute on the planet list in the normal page markup, so it's available without a background call. I'll forward that specific suggestion to the devs.


    5) Empire standalone JSON — hourly/per-second bug

    Forwarded as a clear beta regression — good catch comparing against the resource bar and accountInfo.


    On the itemNames note: can you clarify what you mean by "now maps item UUIDs to names instead of technology id → name"? Items are identified by UUID, not technology ID, so I'm not sure what mapping you were expecting or where you'd previously seen a technology-id-keyed version. A before/after example (or the exact field) would let me pass it along accurately.