Build requirements

Games are uploaded as .zip archives.

The archive must contain an index.html file at its root.

That’s it.

Maximum ZIP size: 1 GB.

The build is validated when it is uploaded. If any validation check fails, the entire build is rejected, and the errors are shown on the Builds page.

Allowed file types

Only files with one of the following extensions are served:

html htm js mjs wasm data symbols mem
css json txt xml md toml png jpg
jpeg webp gif avif ico cur mp3 ogg
wav webm mp4 m4a woff woff2 ttf otf
pck unityweb bundle bin atlas glb gltf

Any other file is left out of the build. It does not cause a rejection, and the Builds page lists what was left out. If your game loads such a file at runtime, such as an .svg image, convert it to a supported type.

Archives inside the build are left out too, never unpacked: .zip, .gz, .tgz, .tar, .bz2, .xz, .7z, .rar, .jar, .war, .apk. Common leftovers are left out without being listed: .DS_Store, Thumbs.db, desktop.ini, _headers, _redirects, *.import, __MACOSX/.

Duplicate paths by case

The build cannot contain two paths that differ only by capitalization, such as assets/player.png and assets/Player.png. The game is served from a case-insensitive origin, so those paths would conflict.

Also rejected

• Symlinks and hard links.
• Windows reserved names as a file or folder name, such as con.js or aux.png, and names ending in a space or a dot.
• Two entries that resolve to the same path.
• A path over 1,024 characters, a single name over 255, or a name with a control character.
• Absolute paths and paths that climb out of the archive with “..”.

Size limits

The compression-ratio limit can affect large files containing mostly empty or repetitive data.

HTML and scripts

The entry document must contain exactly one <head> element and must parse unambiguously. The platform injects the Spiced SDK into it, so malformed or incomplete HTML is rejected rather than repaired.

Scripts must be files in the build

Inline JavaScript never runs, and an upload containing an inline <script> block is rejected. Every script must be its own file in the archive:

<script src="./main.js"></script>

This is the default export from some engines: Godot’s stock web shell boots from an inline block, and single-file exports inline the whole game. Move that code into a .js file in the archive and load it with src.

The same applies to script written into an attribute, which is rejected for the same reason: an event-handler attribute such as onclick or <body onload="init()">, and a javascript: URL in an href or a form action. Attach these from your .js file with addEventListener instead.

External scripts

A script tag cannot load from anywhere but the archive. That rules out absolute URLs, protocol-relative URLs (//...), data: URLs and blob: URLs in a <script> tag, which are rejected at upload. Bundle every dependency into the build. At play time a blob: URL your code creates is allowed by the policy.

Frames

An <iframe> can load a page from your own build, by relative path. A frame onto any other site never loads, so an upload with a page that frames one is rejected. Upload the game files themselves, not a page that embeds a game hosted elsewhere.

script-src 'self' 'unsafe-eval' 'wasm-unsafe-eval' blob:

platform.json

platform.json is optional. A ZIP containing index.html at its root is a valid build without one.

Add one when you need engine metadata, viewport hints or remote configuration:

{
  "engine": "godot",
  "name": "My Game"
}

It must sit at the root of the archive and may be up to 16 KB. Unknown keys and values with the wrong type cause the entire manifest to be rejected.

Phones and small screens

The play page is one 44 pixel bar and then your game. The frame fills everything under it, at whatever size and shape the device is. Nothing scales, letterboxes or rotates your build for you, so a game that only lays out at one size gets cropped rather than fitted.

Two declarations describe a build's mobile support and neither of them enforces anything, so both are promises you keep in the build itself:

• min_width and min_height in platform.json are shown to moderators and on the store page, as “Best at 1280 × 720 or larger”. Nothing stops a phone opening a game that declares 1280×720. Declare the smallest page you actually lay out for, not the desktop one you designed first.
• This game plays on phones and tablets on the listing is your own claim, and it is what players filter the catalogue on. Leave it unticked until the game is playable on a phone you have held.

Spiced SDK

The SDK is optional. A game that never calls window.spiced is a complete game on the platform. It adds player identity, saved games, leaderboards, analytics events, remote configuration and in-game items.

await window.spiced.ready();

if (await window.spiced.isSignedIn()) {
  const user = await window.spiced.getUser();
  console.log(user.displayName);
}

The platform injects the SDK into the entry document when a build is uploaded. Do not add a <script> tag for the SDK to your game. The version is pinned to the build when it is injected, so upload the build again to receive a newer one.

The SDK is not a security boundary. It runs in the same origin as your game and can be modified or replaced by game code. Security-sensitive validation is performed on the server.

spiced.save(data).catch((error) => {
  if (error.code === 'rate_limited') retryLater();
});

Signed-out players

Games can be played without an account: a free listing, and the demo of any listing, let a player skip sign-in entirely. Check isSignedIn() before calling account-dependent methods. When no player is signed in:

• track() does nothing.
• getUser(), getIdentityToken(), save(), load(), submitScore(), getScores() and getItems() reject.
• getConfig() works as usual.
• purchaseItem() resolves, and the platform shows the player a notice with links to create an account or sign in (in a demo, a notice that items cannot be bought there). No purchase starts and onItemsChanged does not fire.
• ready(), isSignedIn(), reportEvent(), signalReady() and openExternal() work as usual.

A signed-in demo session is different: the player has an account, but the session cannot write. getUser() and getScores() still succeed, load() resolves null as if there were no save, and only submitScore() and save() reject.

A playtest (beta) build session has its own saves: save() and load() work, but never reach the released game’s. submitScore() rejects, purchaseItem() starts no purchase, and track() records events but earns the player no Spice.

Events

Use track() to record analytics events. Names are lowercase words separated by dots, and an event may carry up to 10 attributes. A session may send at most 600 events per hour; events past that limit are dropped the same way an invalid event is.

window.spiced.track('level.complete', {
  level: '3',
  time_ms: '42000',
});

If an event fails validation, the entire event is dropped. track() still resolves, so invalid events appear as missing analytics rather than runtime errors.

^[a-z][a-z0-9_]*(\.[a-z0-9_]+)*$

^[a-z][a-z0-9_]*$

Leaderboards

submitScore() and getScores() are available to every game, and every game automatically gets a leaderboard on its store page once 3 players have scored. No additional setup is required.

spiced.submitScore(4200);

The store leaderboard:

• shows the top 25 players
• uses Spiced display names
• shows each player’s best score
• adds a Today tab beside the all-time board once a score has been submitted today, covering one UTC day and resetting at midnight UTC

You do not need to build a leaderboard UI yourself, or track personal bests. Use getScores() when you want a leaderboard inside the game: it resolves to { entries } holding the same top 25, one row per player at their best score, with game-scoped player IDs rather than display names.

const { entries } = await spiced.getScores();
for (const row of entries) {
  draw(row.rank, row.score, row.playerId);
}

// Today's board instead, resetting at midnight UTC.
const today = await spiced.getScores({ period: 'daily' });

Both boards hold the same scores; the daily one is narrowed to the current UTC day. Nothing needs turning on, and a game that never asks for the daily board is unaffected by it.

Submit a score when the game enters its end state, not on every frame while the end state is active. Scores must be whole numbers, and submitScore() rejects when nobody is signed in. On a free listing’s full build that score still goes on the board at once as “Anon #NNNN”, and an account the player then makes puts their name on it. A signed-out score in a demo is dropped.

A stored score is not necessarily a visible score. A resolved submitScore() promise means the score was stored, not that it passed every leaderboard check. The SDK does not expose which server-side check affected a submission. A board is also not a roster of named players: a player can take their name off leaderboards in their profile settings, and their rows then appear under an anonymous label, and a score set while nobody was signed in appears the same way.

// Posts every frame while the game-over screen is displayed.
if (world.phase === 'over') {
  spiced.submitScore(world.score);
}

// Submit once when the run transitions from playing to over.
const wasPlaying = world.phase === 'playing';

update(world, step);

if (wasPlaying && world.phase === 'over') {
  spiced.submitScore(world.score);
}

spiced.submitScore(score).catch(() => {
  // Handle or ignore submission failure.
});

-1,000,000,000,000

Verified leaderboards

Verified is an optional anti-cheat system that validates score submissions against a declared set of game rules. Configure it from the Anti-cheat tab on your game’s page in the developer dashboard, where you declare a maximum reachable score and, for each action, its maxCount, maxValue and minIntervalMs.

During gameplay, call reportEvent() for each declared action. The action log is attached to the next score submission, and the server replays it against the manifest before confirming the score.

spiced.reportEvent('coin.collect', 10);
spiced.reportEvent('level.finish');

// Later:
spiced.submitScore(4200);

Your own backend

A build cannot reach the network beyond the platform API by default. To call a server you run, list its origins on the listing page under Backend origins: plain https:// origins, up to 4. A moderator admits them at review, and once admitted the game’s policy allows network calls to them, so fetch, WebSocket (wss:// on the same host is covered) and EventSource to those hosts work. Nothing else in the policy changes. Your server has to answer CORS for the game’s origin, which is the Origin header on each request.

Third-party ad networks are not allowed on Spiced, so an ad network’s servers are not admitted.

Knowing who is calling

Send getIdentityToken() as a bearer token and verify it on the server. It is a JWT signed with ES256, valid for 5 minutes, with keys published at /sdk/jwks on the API origin (). Check iss is the API origin, aud is your game id, and alg is ES256; sub is then the same game-scoped player id getUser() returns. The token grants nothing on the platform API.

// In the game
const token = await window.spiced.getIdentityToken();
await fetch('https://api.example.com/score', {
  method: 'POST',
  headers: { Authorization: 'Bearer ' + token },
  body: JSON.stringify({ score }),
});

// On your server (Node, jose)
import { createRemoteJWKSet, jwtVerify } from 'jose';
const keys = createRemoteJWKSet(new URL('/sdk/jwks', ''));
const { payload } = await jwtVerify(token, keys, {
  issuer: '',
  audience: GAME_ID,
  algorithms: ['ES256'],
});
const playerId = payload.sub;

Seeing your own traffic

You already get traffic without any of this: your game’s Analytics tab shows plays, sessions and unique players on its own, and track() records any custom events you add. Reach for a beacon only when you want that data in an analytics service you already run.

To do that, add that service’s origin under Backend origins above, then send it a small fire-and-forget beacon from the game. Send counts and events, not players: they have not agreed to a third party profiling them, so keep their identity and what they do in the game out of the payload.

// In the game: a fire-and-forget beacon to your own service
const body = JSON.stringify({ event: 'play_start', at: Date.now() });
navigator.sendBeacon('https://analytics.example.com/collect', body);

// Or fetch, when you need the response
await fetch('https://analytics.example.com/collect', {
  method: 'POST',
  keepalive: true,
  headers: { 'content-type': 'application/json' },
  body,
});

This sends data out to a host you named. Loading a third party’s hosted analytics tag is the opposite direction and stays blocked.

Do not load code from your backend. The game must run only the code in the reviewed build. Fetching script from your own server and running it is not allowed, even though the policy does not block it.

Where to go next

• Start publishing
• Pricing
• Become a founding developer
• Support