> ## Documentation Index
> Fetch the complete documentation index at: https://summer-18f03259-codex-native-multiplayer-entry.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Submit Your Summer Game for Review

> Choose a deployed submission path for a Summer game, understand validation and human review, then follow the update loop.

## Before you submit

* Creator gameplay scripts authored in GDScript
* Valid [`manifest.json`](/api-reference/summer-sdk/manifest-json-reference) at the pack root
* Entry scene root `extends SummerGame`
* No [banned APIs or reserved paths](/api-reference/summer-sdk/banned-apis-reference)
* [Local testing](/api-reference/summer-sdk/testing-your-game-locally) passes

## The two deployed submission paths

### Path A — the release API (recommended; agents and CI)

Four JSON/HTTP calls against `https://summercraft.ai`: create game → presigned upload URL → PUT the `.pck` → finalize with server-side sha256 verification. Artifact limits: 1024 bytes – 512 MiB. Each write step is limited to 1 request per hour per account.

Full request/response reference: [Exporting and Uploading Your Game](/api-reference/summer-sdk/exporting-and-uploading-your-game). Agent bootstrap: [/agent-setup](/agent-setup).

### Path B — the browser submit page

Go to [summercraft.ai/submit](https://summercraft.ai/submit) signed in, and upload two files:

* the `.pck` (multipart field `pck`)
* `manifest.json` (multipart field `manifest`, file or JSON text)

The page posts a multipart request to the platform API:

```bash theme={null}
curl -X POST "https://crafty-production-5a7c.up.railway.app/games/submit" \
  -H "Authorization: Bearer <SUPABASE_ACCESS_TOKEN>" \
  -F "pck=@./game.pck" \
  -F "manifest=@./manifest.json;type=application/json"
```

(The Railway hostname is the deployed platform-api identity — it is correct as written.)

This path validates at upload time:

* auth and creator identity,
* required manifest fields and basic typing,
* max upload size (2 GB on this path),
* **automated static analysis** of `.gd` files and scripts embedded in `.tscn`/`.tres`: banned APIs, reserved paths, blocked binary/native extensions. Failures return `error: "Static analysis failed"` with a `violations` list (file, line, pattern).

On success it returns `ok: true`, `gameId`, `submissionId`, `status: "review"`.

<Note>
  The static scanner is pattern-based. A banned API inside a dead branch, an editor-only check, or a comment-adjacent string still fails. Do not generate "fallback" code paths that use blocked APIs. On Path A there is no automated scanner at upload time — the same rules are enforced by human review instead, so a violation costs you a review round-trip rather than an instant error.
</Note>

## Review lifecycle — both paths

Every submission is reviewed by a human. No auto-publish.

| State                       | Meaning                                                                                                                                 |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `draft`                     | Game record exists, nothing submitted or approved yet                                                                                   |
| `pending_review` / `review` | A release/submission is in the admin queue                                                                                              |
| `published`                 | Approved catalog state — the release is active and downloadable under the documented access rules, but not yet playable on the platform |
| `rejected`                  | Rejected with a written reason, shown to you on [summercraft.ai/creator](https://summercraft.ai/creator)                                |

On Path A, approval re-verifies the stored artifact against the checksum pinned at finalize
before the game's active version moves — verification at upload is not trusted at approval
time. A rejected update leaves the previously approved catalog release active.

**Honest status:** approval publishes your game on the platform and makes its release
downloadable through the authenticated
[download endpoint](/api-reference/summer-sdk/exporting-and-uploading-your-game). Playing
uploaded Summer games in the browser or desktop shell, and hosted dedicated game servers,
automatic matchmaking, and the runtime sandbox are not live yet — do not tell players
otherwise. See the canonical
[platform capability status](/knowledge-base/source-status#platform-capability-status).

## Updating an existing game

Released versions are immutable.

1. Keep `manifest.id` (and on Path A the `gameId`) stable.
2. Bump `manifest.version`; on Path A pass the same new version string to upload-url and finalize.
3. Re-export and re-submit.

Each update goes through review again. The previously approved catalog release stays active
while its update waits.

## Common submission errors

Path A errors are self-describing JSON (`{ "error", "detail" }`) — the `detail` names the fix. The full table is in [Exporting and Uploading](/api-reference/summer-sdk/exporting-and-uploading-your-game). Path B errors:

* `Missing .pck file (multipart field: pck)`
* `Uploaded file must be a .pck`
* `PCK file too large (... max 2GB)` — trim assets, or contact [founders@summerengine.com](mailto:founders@summerengine.com) for large-upload onboarding
* `Invalid manifest. Required: id, name, version, summer_sdk, entry_scene, min_players, max_players`
* `Static analysis failed` (with violations list)

<CardGroup cols={2}>
  <Card title="Previous: Export and upload" icon="arrow-left" href="/api-reference/summer-sdk/exporting-and-uploading-your-game">
    Return to pack creation and the release API reference.
  </Card>

  <Card title="Next: Update an existing Summer game" icon="arrow-right" href="/api-reference/summer-sdk/updating-your-game">
    Keep the identity stable, bump the version, retest, and resubmit.
  </Card>
</CardGroup>