SDK reference

Everything a game can say to the portal and everything the portal can say back. The tables are generated from the real schemas, constants and rules in @gameportal/sdk-types, so they cannot drift from the code; the prose around them is hand-written. If the words handshake, port or standalone are new to you, read Concepts first.

Packages #

Today these are packages of the GamePortal repository; a game lives next to them in games/<id>. They are published for external developers when the programme opens (V2), with the same names and the same API.

The bridge #

createBridge() is the only thing most games need. It does the handshake, keeps the save, paces everything under the platform limits and falls back to standalone mode when the page is opened on its own.

import { createBridge } from "@gameportal/game-bridge";

const bridge = createBridge({ gameId: "my-game", gameVersion: "1.0.0", saveVersion: 1 });

// Register every handler BEFORE start() so that no message is missed.
bridge.on("pause", () => freezeGame());
bridge.on("resume", () => showTapToContinue());
bridge.on("lang", ({ lang }) => setLanguage(lang));
bridge.start();

// "portal", "standalone" or "unsupported". Inside the portal this waits for `init`, however long it takes.
const mode = await bridge.whenSettled();

if (mode === "unsupported") {
  showCalmScreen();
} else {
  const saved = bridge.storage.load(); // the cloud save in the portal, localStorage when standalone
  startGame(parseSave(saved?.data), bridge.init?.lang);
  bridge.ready(); // the first frame is up and input works
}

createBridge(options) #

Properties and methods #

score() and event() do not pace themselves: at most one score per second and five events per second reach the portal without rate_limited. Space them in your game (the starter's src/pacing.ts does). A request that gets no ack within 15 seconds resolves as { ok: false, error: "network" }.

Bridge events #

The save event carries one of these statuses:

Storage #

bridge.storage is the only place a game keeps progress. In the portal it is the cloud save; standalone it is localStorage. The game's code is the same in both.

Conflicts #

A conflict means two copies of the progress exist and the portal will not decide which one wins: a player has the game open on a phone and a laptop, or signed in on a device that played as a guest. Handle it one of two ways.

Merge without asking when the save can only grow (best scores, unlocked items, settings): combine both and keep going. The starter does this.

bridge.on("save", (status) => {
  if (status.status !== "conflict") return;
  const merged = mergeSaves(bridge.storage.load()?.data, status.conflict.data);
  bridge.storage.save(merged); // replaces the pending state while the bridge is blocked
  bridge.storage.resolveConflict("local"); // sends it on top of the server's revision
});

Ask the player when the two copies cannot be merged (a campaign position, an idle game's money). Show both, say how old they are (conflict.savedAt), and apply the choice:

bridge.on("save", (status) => {
  if (status.status !== "conflict") return;
  const choice = askPlayer(bridge.storage.load()?.data, status.conflict);
  const chosen = bridge.storage.resolveConflict(choice);
  startGame(parseSave(chosen), bridge.init?.lang);
});

Whatever the player chooses, the other save stays in the server's save history (the newest five per player and game), so nothing is lost for good.

Save formats #

Every save carries the saveVersion of its format. When your format changes, raise saveVersion in the manifest and in createBridge(), and add one upgrade step per change. upgradeSaveData runs them in order:

import { createBridge, upgradeSaveData } from "@gameportal/game-bridge";

const STEPS = {
  // version 1 -> 2: the single `coins` number became an object
  1: (data: unknown) => ({ wallet: { coins: (data as { coins?: number }).coins ?? 0 } }),
  // version 2 -> 3: a new field with a default
  2: (data: unknown) => ({ ...(data as object), muted: false }),
};

const SAVE_VERSION = 3;

export const bridge = createBridge({
  gameId: "my-game",
  gameVersion: "1.2.0",
  saveVersion: SAVE_VERSION,
  upgradeSave: (data, fromVersion) => (fromVersion === null ? data : upgradeSaveData(data, fromVersion, SAVE_VERSION, STEPS)),
});

A save from a newer format than the build is never loaded and never overwritten: the bridge emits outdated and stops saving, and the portal itself refuses the write with conflict. That protects the player when an old tab or a rolled-back release meets a save written by a newer one.

Protocol #

The bridge speaks the protocol for you. This section is the contract itself: for your tests, for engines that cannot use the bridge (Unity and similar) and for anyone who wants to know what crosses the wire.

Envelope #

Every message has the same shape: { sdk: "portal-sdk", v: 1, type, id, payload }.

Limits #

A message that exceeds a limit is not executed: the portal answers with an ack that carries rate_limited or too_large.

Messages at a glance #

The first two messages, hello and init, travel with window.postMessage. init brings a MessageChannel port with it, and everything after that, in both directions, goes over the port. The game never listens to window messages once the port exists.

game (iframe, games origin)                           portal (portal origin)
 start()   hello ------- postMessage(msg, portalOrigin) ------->   checks event.source and event.origin
           (again every 250 ms until init arrives, and once more after the window's load)
           <------------ init + MessageChannel port -----------    language, guest flag, save, server time, challenge, limits
 ready     ready --------------- port ----------------------->    hides its loading screen
 playing   session, save, score, event ---- port ----------->      ack for save, score and event
           <---------- pause, resume, lang, day, ack ---------

hello message #

Game to portal. The first message of every session, sent only when the page runs inside an iframe (window.parent !== window).

Direction: game to portal. Sent over: window.postMessage with an exact target origin. Answered by: init (or an ack with unsupported_version).

When: The game loaded inside an iframe. Repeated every 250 ms until init arrives, and once more (same id) after the window's load event, even after init: the portal closes a frame whose document finished loading without a hello after that load (navigation watchdog).

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "hello",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "gameId": "my-game",
    "gameVersion": "1.0.0",
    "sdkVersions": [1]
  }
}

The portal accepts a hello only when event.source is the frame it created and event.origin is the origin it expected for that game. The game sends it once to each allowed portal origin, with an exact target origin and never "*". If the game reloads, the new page sends a new hello with a new id; the portal closes the old port and sends a new init.

init message #

Portal to game, with one MessageChannel port transferred. The game accepts it only from window.parent at one of the allowed portal origins.

Direction: portal to game. Sent over: window.postMessage with an exact target origin. Answered by: nothing (no ack).

When: Answers the first valid hello; carries the MessageChannel port. Can be sent again over the port (new session, after a session renewal).

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "init",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "sdkVersion": 1,
    "lang": "en",
    "player": {
      "guest": true
    },
    "save": {
      "data": {
        "coins": 120,
        "level": 3
      },
      "revision": 7,
      "savedAt": "2026-10-17T20:41:12.000Z",
      "saveVersion": 1
    },
    "time": {
      "serverTime": "2026-10-17T22:58:00.000Z",
      "day": "2026-10-18",
      "nextResetAt": "2026-10-18T21:00:00.000Z"
    },
    "challenge": {
      "metric": "round_score",
      "target": 300,
      "progress": 140,
      "endsAt": "2026-10-18T21:00:00.000Z"
    },
    "limits": {
      "maxSaveBytes": 262144,
      "minSaveIntervalMs": 30000
    }
  }
}

Nothing about the player reaches the game except player.guest: no id, no name, no e-mail, no session key. Everything in save.data is the game's own data from an earlier session and must be parsed as untrusted input.

ready message #

Game to portal, over the port. Send it once the first screen is drawn and input works. The portal hides its loading screen; it shows a retry screen and reloads the frame if ready has not arrived 10 seconds after the frame loaded. The platform rule asks for 3 seconds.

Direction: game to portal. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: The first screen is drawn and accepts input. Once per init.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "ready",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "saveVersion": 1
  }
}

save message #

Game to portal. The bridge builds this from storage.save(); you rarely write one yourself.

Direction: game to portal. Sent over: the MessageChannel port. Answered by: ack.

When: The save changed (paced to one per 30 s) and immediately on pause or a hidden tab.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "save",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "data": {
      "coins": 135,
      "level": 3
    },
    "baseRevision": 7,
    "saveVersion": 1
  }
}

The portal stores the save with an optimistic lock: baseRevision must equal the stored revision, otherwise the answer is conflict. A save from a lower saveVersion than the stored one is a conflict too. Every replaced save, and every save refused with a conflict, is kept in the save history.

score message #

Game to portal. A score is whatever number the game ranks players by, normally sent at the end of a round (not every frame).

Direction: game to portal. Sent over: the MessageChannel port. Answered by: ack.

When: A score worth ranking was reached, normally at the end of a round. At most one per second.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "score",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "mode": "round_score",
    "value": 240
  }
}

An undeclared mode is refused with invalid. A declared mode is checked against its plausibility rules: a score that breaks them is stored as suspicious and never reaches a leaderboard, but the game still gets ok: true and is not told.

event message #

Game to portal. Events feed badges and the daily challenge.

Direction: game to portal. Sent over: the MessageChannel port. Answered by: ack.

When: Something meaningful for badges and daily challenges happened. At most 5 per second.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "event",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "name": "round_end",
    "props": {
      "score": 240,
      "hits": 18
    }
  }
}

The event must be declared in the manifest, and every property too, with the declared type; otherwise the answer is invalid.

session message #

Game to portal. It says whether the player is really playing right now. The portal sends its own heartbeats and counts active play time from them, so a game sends session only when activity changes (a round starts, a round ends, the game is paused), never as a heartbeat.

Direction: game to portal. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: The player starts or stops really playing. Only on a change.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "session",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "active": true
  }
}

pauseRequest message #

Game to portal. The player pressed Esc or P inside the game. The bridge listens for both and sends this by itself, so a game built on the bridge does nothing; the portal then pauses the game the same way as its own Pause button (pause with reason: "overlay"). A game that speaks the SDK without the bridge may send it when its own pause key is pressed. The bridge sends nothing while the portal has the game paused, the portal ignores it before ready, while an ad break plays and when the game frame does not have the focus, and an older portal drops it with a warning only. P counts only without Shift, Ctrl, Alt or Meta, not on a held key's repeats and not while a text field has the focus (isPauseKey from @gameportal/game-bridge is the exact test). A game that needs P for play passes pauseOnKeyP: false to createBridge (the game-kit hosts take the same option) and keeps Esc only. Esc and P are reserved while embedded: do not bind your own pause or menus to them in portal mode (check host.embedded; game-kit's bindPauseKeys does it for a game's own pause outside the portal).

Direction: game to portal. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: The player pressed Esc or P inside the game. The bridge sends it by itself; the portal then pauses the game with pause { reason: "overlay" }.

The payload is an empty object.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "pauseRequest",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {}
}

pause message #

Portal to game. Freeze game time, animation and audio, say session(false), and wait for resume.

Direction: portal to game. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: The tab is hidden, or the portal shows something over the game.

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "pause",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "reason": "overlay"
  }
}

A hidden tab is a pause too, but the browser tells the game that itself (visibilitychange); handle both as one "suspended" signal. The bridge flushes the pending save on pause.

resume message #

Portal to game. Continue. In the middle of a round, wait for a tap before the round goes on. Time that passed while paused is measured with serverTime, never with the device clock.

Direction: portal to game. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: The pause ended. Carries the current server time.

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "resume",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "serverTime": "2026-10-17T23:02:30.000Z"
  }
}

lang message #

Portal to game. Switch the language without reloading. In the portal the game hides its own language button: the portal owns the language.

Direction: portal to game. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: The player changed the portal language.

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "lang",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "lang": "tr"
  }
}

day message #

Portal to game. The player's local day changed while the game was open. Restart daily counters and daily content here, and nowhere else: not at local midnight, not when the device clock says so.

Direction: portal to game. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: The session crossed the player's local midnight.

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "day",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "day": "2026-10-19",
    "nextResetAt": "2026-10-19T21:00:00.000Z",
    "challenge": {
      "metric": "round_score",
      "target": 300,
      "progress": 0,
      "endsAt": "2026-10-19T21:00:00.000Z"
    }
  }
}

ack message #

Portal to game. The answer to every save, score and event, and the unsupported_version answer to a hello. It refers to the message it answers with payload.for.

Direction: portal to game. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: Answers every save, score and event.

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "ack",
  "id": "7a9e2d04-1b6f-4c3d-9e8a-5f4b3c2d1e0f",
  "payload": {
    "for": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
    "ok": false,
    "error": "conflict",
    "conflict": {
      "revision": 9,
      "data": {
        "coins": 410,
        "level": 4
      },
      "savedAt": "2026-10-17T22:55:00.000Z",
      "saveVersion": 1
    }
  }
}

Optional ad messages (adBreak, adOffer, adReward, adBreakResult) #

Optional and backwards compatible: send them only when init.features.adBreaks is true, which means the portal shows ads for this game. Ads run on the portal page (H5 Games Ads), never inside the game. A game never blocks on an ad: with the bridge, bridge.ads.adBreak({ type, name, onOffer }) always resolves, with unavailable when there is no ad. A rewarded ad grants nothing on the portal side (no XP); the game may give an in-game cosmetic or a continue only after viewed.

adBreak message #

Direction: game to portal. Sent over: the MessageChannel port. Answered by: adBreakResult.

When: Optional (only when init.features.adBreaks is true): a natural break where an ad may run (start, pause, next, browse) or a rewarded offer (reward). The portal decides and may answer unavailable; never block the game on it.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "adBreak",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "type": "next",
    "name": "level_end"
  }
}

adOffer message #

Direction: portal to game. Sent over: the MessageChannel port. Answered by: adReward (no answer within 60 s counts as no).

When: A rewarded ad is ready for the adBreak named in for; ask the player.

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "adOffer",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "for": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c"
  }
}

adReward message #

Direction: game to portal. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: The player's answer to an adOffer: watch the rewarded ad (show: true) or not.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "adReward",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "for": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
    "show": true
  }
}

adBreakResult message #

Direction: portal to game. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: How the adBreak ended: shown, dismissed, viewed (grant the in-game reward only now) or unavailable. The portal grants nothing itself.

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "adBreakResult",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "for": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
    "status": "viewed"
  }
}

Online matches (multiplayer addendum) #

Optional. A game whose manifest declares multiplayer and whose portal sets init.features.multiplayer may send these. The server referees every move (ADR-008); the game only draws what mp_state says.

mp_request message #

Direction: game to portal. Sent over: the MessageChannel port. Answered by: ack, then mp_start or mp_cancel.

When: Optional (only when init.features.multiplayer is true): the player chose "play a friend" (invite) or "quick match" (quick). The portal opens its own lobby over the game. At most one per 2 s.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "mp_request",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "mode": "invite"
  }
}

mp_move message #

Direction: game to portal. Sent over: the MessageChannel port. Answered by: ack (conflict: stale seq or not your turn; invalid: illegal move).

When: The player's move in an online match, built on the latest mp_state seq. The server referees it; the board changes only when the next mp_state arrives. At most 4 per second, 1 KB of JSON.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "mp_move",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "matchId": "5c1d7e9a-2b3f-4a6c-8d0e-1f2a3b4c5d6e",
    "seq": 4,
    "move": {
      "pit": 2
    }
  }
}

mp_emote message #

Direction: game to portal. Sent over: the MessageChannel port. Answered by: ack.

When: A preset reaction (there is no free text). One per 3 s. The opponent's game receives an mp_emote from the portal with the sender's seat.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "mp_emote",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "matchId": "5c1d7e9a-2b3f-4a6c-8d0e-1f2a3b4c5d6e",
    "emote": "well_played"
  }
}

mp_resign message #

Direction: game to portal. Sent over: the MessageChannel port. Answered by: ack.

When: The player gives up the online match; the final mp_state follows with reason resign.

The portal validates this payload strictly: unknown fields make the message invalid.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "mp_resign",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "matchId": "5c1d7e9a-2b3f-4a6c-8d0e-1f2a3b4c5d6e"
  }
}

mp_start message #

Direction: portal to game. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: A match was found, or resumed after a reload (resumed: true). An mp_state follows at once.

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "mp_start",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "matchId": "5c1d7e9a-2b3f-4a6c-8d0e-1f2a3b4c5d6e",
    "mode": "invite",
    "resumed": false,
    "turnSeconds": 30,
    "you": {
      "seat": 0,
      "seatId": "0123456789abcdef",
      "handle": "1A2B3C4D",
      "guest": true
    },
    "opponents": [
      {
        "seat": 1,
        "seatId": "fedcba9876543210",
        "handle": "9F8E7D6C",
        "guest": false
      }
    ]
  }
}

mp_state message #

Direction: portal to game. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: The server's state of the match after every move (yours, the opponent's or the server's auto-move on a timeout), and at the end. Always draw this, never a locally predicted board.

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "mp_state",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "matchId": "5c1d7e9a-2b3f-4a6c-8d0e-1f2a3b4c5d6e",
    "seq": 5,
    "status": "active",
    "toMove": 1,
    "deadlineAt": "2026-10-19T18:00:30.000Z",
    "serverTime": "2026-10-19T18:00:00.000Z",
    "state": {
      "board": [4, 4, 1, 5, 5, 5, 1, 4, 4, 4, 4, 4, 4, 0],
      "toMove": 1,
      "over": false,
      "moves": 1,
      "last": null
    },
    "lastMove": {
      "seat": 0,
      "move": {
        "pit": 2
      },
      "auto": false
    },
    "result": null,
    "connected": [true, true]
  }
}

mp_cancel message #

Direction: portal to game. Sent over: the MessageChannel port. Answered by: nothing (no ack).

When: The lobby closed without a match. fallback_ai: the player chose to play the computer instead.

Written by the portal. Games should ignore fields they do not know: later revisions of v1 may add some.

{
  "sdk": "portal-sdk",
  "v": 1,
  "type": "mp_cancel",
  "id": "3f2b8c1a-5d4e-4f6a-8b7c-9d0e1f2a3b4c",
  "payload": {
    "reason": "fallback_ai"
  }
}

Error codes #

The game decides what to do with each code; the platform rules (R-SDK-11) check that it never loops on one, never shows the player a raw error and never loses a save to one.

Utilities in @gameportal/sdk-types #

import { MAX_SAVE_BYTES, gameManifestSchema, measureJson } from "@gameportal/sdk-types";

export function checkSave(save: unknown, manifest: unknown): void {
  const size = measureJson(save, MAX_SAVE_BYTES);
  if (!size.ok) throw new Error(`the save is ${size.error}`); // "invalid" (not plain JSON) or "too_large"
  console.log(`the save is ${size.bytes} bytes of ${MAX_SAVE_BYTES}`);
  gameManifestSchema.parse(manifest); // throws a readable error when a field is wrong
}

If your engine cannot use the bridge, implement the protocol above exactly and run pnpm check: the runner holds every game, bridge or not, to the same rules (R-SDK-01 only asks you to prefer the bridge).