Publish the game to its sandbox
publish_sandboxPublish this archive to the game’s sandbox — a public page anyone with the link can play, without moderation. Ask the developer first. Before calling, read get_sandbox_state with the same archiveId: its publish says whether this call would be refused, in the same words. A publish needs the build check PASSED (get_archive_status state), Playgama Bridge 2.2.0 or newer in the build, all three covers and a complete form. Answers outcome PENDING: the archive is built, then published, as a rule within minutes; url is the sandbox’s link, revision what is live until then (null before the first publication). Follow the PLAYGAMA_SANDBOX publication of get_publications, waiting its retryAfterSeconds between reads: PUBLISHED — the build is live, hand out url; FAILED — it did not go live and no reason is given: tell the developer, a new publish starts over. Until it is PUBLISHED or FAILED, another publish is refused with 409: wait and call again. Refusals (reason; relay message word for word): ARCHIVE_PENDING — if get_archive_status already says DONE, upload again; MULTIPLAYER — the sandbox has no player accounts: uncheck the flag only if the game plays single-player; PUBLISHED_ON_PLAYGAMA — the game is live in the catalog, its sandbox is closed for good; BLOCKED — Playgama blocked this sandbox, a publish cannot lift it; RATE_LIMITED — 15 publications per rolling hour, repeats included: wait; ORG_QUOTA — wait until resetsAt, do not retry. The rest name what to fix: the build check’s own reasons (get_bridge_sdk_docs has the SDK docs), ARCHIVE_FAILED, BRIDGE_VERSION_OUTDATED, BRIDGE_VERSION_UNKNOWN, FORM_INCOMPLETE (details: the fields to fill, the title included), COVERS_INCOMPLETE (emptySlots).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| archiveId | Yes | Id of an archive of this game that is in its form, unpacked and past its build check (get_archive_status says `processing: DONE` and `state.status: PASSED`), built on Playgama Bridge 2.2.0 or newer (`analysis.bridgeVersion`) | |
| updateNote | No | What a returning player will notice in this build, 80 to 500 characters, 1 to 4 sentences. Not a changelog: pick the one or two changes a player would actually feel (a new level, controls that work differently, a boss that got easier) and say them the way you’d tell a friend who played last week. Skip refactors, build settings and fixes nobody could see. If it fixes something players complained about, say so. Send it when this archive replaces the live one (get_sandbox_state `archiveChanged`); leave it out on a first publication and when a player would notice nothing. It is kept with this publication. Always write it in English, even when you talk to the developer in another language: translate, don’t switch. Write as the developer posting in the game’s chat, not as an announcement: first person, short sentences, contractions, plain words, one or two short paragraphs. Plain text only: no headings, lists, markdown, links, e-mail addresses or hashtags, and one emoji at most. Avoid ad words and AI tells: immersive, dive into, embark, journey, unleash, elevate, seamless, thrilling, "whether you’re…", "not just X but Y", lists of three, em dashes. Don’t open with the game’s title, "Welcome to" or "Hey everyone". Use only what you know from the game and from building it; never invent a backstory, feelings or numbers. Non-Latin letters and links are refused: fix the text or leave it out, and never let it block the rest of the call. | |
| applicationId | Yes | Application (game) id, as returned by list_applications |