PlayDrop

Reference documentation

Catalogue Reference

Playdrop has a creator catalogue, not just a publish endpoint.

Updated April 6, 2026

Catalogue Reference

Playdrop has a creator catalogue, not just a publish endpoint.

The catalogue contains versioned apps, assets, and packs. It is also where discovery, comments, likes, saves, remixing, and creator management connect with the CLI and the web app.

Use this page when you need to understand:

  • what can be published
  • how published objects are identified
  • how search, browse, and detail work
  • how social and discovery signals fit into the platform
  • how the CLI and web app operate on the same catalogue objects

Apps, Assets, and Packs

Playdrop publishes three core catalogue objects:

  • apps: playable experiences such as games, demos, tools, and templates
  • assets: reusable content such as images, music, SFX, video, and 3D files
  • packs: versioned bundles of asset refs

These objects are one shared creator model:

  • a workspace can publish all three through catalogue.json
  • creators can browse and remix all three from the CLI and the web app
  • hosted apps can consume assets and packs again at runtime

Canonical refs

The CLI and docs use canonical refs to identify published objects:

text example

playdrop/app/hangingout
playdrop/asset/sample-asset
playdrop/pack/starter-pack

Use exact version refs when you need remixing or repeatable automation:

text example

app:playdrop/hangingout@1.0.0
asset:playdrop/sample-asset@r1
pack:playdrop/starter-pack@1.0.0

Common CLI operations

Inspect the live catalogue:

bash example

playdrop browse --kind all --limit 25
playdrop search "pixel knight" --kind asset
playdrop detail playdrop/app/hangingout --json
playdrop versions browse playdrop/pack/starter-pack

Create or remix local content from published content:

bash example

playdrop project create app my-app --template playdrop/template/typescript_template
playdrop project create app my-remix --remix app:playdrop/hangingout@1.0.0
playdrop project create asset my-asset --remix asset:playdrop/sample-asset@r1
playdrop project create pack my-pack --remix pack:playdrop/starter-pack@1.0.0

Discovery and Social Signals

Discovery is part of the creator platform, not decorative UI.

Creators should think about catalogue quality in four layers:

  • search and browse discoverability
  • detail-page clarity
  • social proof and conversation
  • remixability and version history

Search and browse

The CLI and the web app both expose the public catalogue:

bash example

playdrop browse --kind app --limit 25
playdrop search "cozy racer" --kind app
playdrop search "sword icon" --kind asset --asset-category IMAGE
playdrop search "starter pack" --kind asset-pack

Search and browse are the first surfaces creators should use when they want to learn what already exists before building or remixing.

Detail, versions, and conversation

Detail and version history give creators the stable object model:

bash example

playdrop detail playdrop/app/hangingout
playdrop versions browse playdrop/app/hangingout
playdrop versions browse playdrop/asset/sample-asset

Use exact versions whenever you need repeatable remixes, deterministic references, or a stable audit trail.

The CLI exposes comments directly:

bash example

playdrop comments browse playdrop/app/hangingout
playdrop comments add playdrop/app/hangingout --body "Clear onboarding and nice pacing."
playdrop comments delete 123

Likes, saves, remixes, and comments are creator-facing platform signals, not just player reactions.

Web and CLI Workflow Mapping

Creators should think of the web app and the CLI as two views over the same platform objects.

The web app is best for

  • catalogue browsing and detail pages
  • creator identity and account setup
  • visual listing review
  • player-facing launch paths
  • account tasks such as generating a CLI API key

The CLI is best for

  • auth from a coding environment
  • project initialization
  • template and remix scaffolding
  • local development
  • validation and publish
  • fast catalogue inspection from the terminal
  1. Inspect the live catalogue in the web app or CLI.
  2. Choose create or remix.
  3. Run local development in the CLI.
  4. Validate and publish.
  5. Return to the web app to review the published listing and creator surface.

Platform Boundary

Playdrop owns the catalogue model, creator identity, version history, canonical refs, and the shared discovery surfaces.

Your project still owns its content, description, listing quality, and the design of what a player can do once they launch your app.