SDK and game integration

Local prototype. The public SDK repository is the distribution destination; the newest bridge and publishing CLI are being verified locally and are not yet confirmed pushed. There is no npm release.

One identity, scoped to your game

An uploaded game runs in Spawn's isolated game frame. Its SDK asks the trusted parent for the signed-in player's game-specific ID, unique Spawn name and optional avatarUrl. It never receives an account cookie, email, database password or publishing key.

The bridge supports identity, load/save, unverified score submission and a request for the fixed 10 TEST entry product. Spawn displays and approves that request outside the game's frame. No runtime method awards funds or approves spending. A game listed as Free cannot request the paid-entry product.

The game connects once through a private message channel bound to its launch. The SDK confirms that the connected document is still loaded before Spawn handles game requests. Navigating or reloading its frame requires a fresh launch from Spawn. Repeated entry requests in the same launch return the existing paid receipt rather than charging again.

A standalone game must clearly identify its practice mode. Never turn a failed platform request into a simulated successful payment.

Store small records

Use version zero to create a record. Updates supply the last expectedVersion; a stale version returns 409. Reload and resolve the conflict before retrying.

Keys use 1–64 letters, numbers, underscores or hyphens. _spawn_ is reserved. Quotas count payload bytes; indexes, database pages and backups require additional disk space. Save at checkpoints, not every frame. Store assets in the browser build, not JSON.

Scores are claims

The server attaches identity and any paid-entry record to a submission. It does not prove that the score is honest. Creators review entries and separately approve dashboard distributions from their available test pool. Client code must never hold a reward or owner credential.

For multiplayer or authoritative game rules, operate your own server. Spawn does not run game simulation or offer universal anti-cheat.

Publish a preview

Create a project on Spawn, download its temporary publishing credential, and copy the setup prompt into your agent. Keep the credential outside the game directory, chat and source control. It allows only that project's upload and status operations; it cannot list a game, edit player records or move funds.

Upload a bundled browser build with index.html. Local limits are 25 MB, 1,000 files and five retained releases per game, with 100 MB of retained builds per creator account. The sandbox currently blocks external scripts, network connections and nested frames; bundle dependencies locally. Native games need a compatible browser export, and some Unity/threaded WASM builds may need changes.

Open the private preview, play it, then explicitly submit the exact build. New listings require Spawn review. GitHub-triggered build workers and public hosting are not configured yet.

Security checklist for your agent

• Treat saves, scores and all browser input as untrusted.
• Keep publishing and server secrets out of browser code and build output.
• Stop paid entry when payment fails or is cancelled; never manufacture a receipt.
• Never automatically reward a client-reported win.
• Run tests and a security review before submission. Codex Security can help find code flaws; it does not certify gameplay or eliminate cheats.

See the API reference for local routes. The older createSpawnClient cookie transport remains restricted to reviewed first-party code; do not use it to bypass game isolation.