CRT/storebound
1
0
Fork 0
Code Issues Pull requests Releases 1 Packages 1 Activity Actions
storebound/docs/api.md
CRT 710c3a53d0 README, docs and site: one story (the whole job, no avoidable rejections, the desktop app, your AI, install) 
README is a short front page (about 120 lines) with one real visual per section; every former section moved
unchanged into docs/*.md with a docs/README.md index (journey, rejections, getting-started, commands, growth,
studios, store-art, listing-languages, api, skills, mcp, safety, faq, project). The site tells the same story on one
page: the teaser in the hero, real CLI output as text, the desktop app as a section with light/dark captures of eight
screens and the per-system downloads (desktop/latest.json); /desktop/ redirects to /#download. New capture tools:
tools/site-desktop-shots.ts (fixture-mode desktop frames) and tools/site-term-shots.ts (real CLI output as text and
WebP). tests/docs-links.test.ts checks README, docs and site links resolve.
2026-10-13 03:29:59 +08:00

2.2 KiB
Raw Blame History

Every endpoint

The commands above cover the journey. For anything else, storebound api calls every operation of the App Store Connect API (1303 operations, OpenAPI 4.5.1) and of the Google Play Developer APIs (Android Publisher v3: 145, Play Developer Reporting v1beta1: 25), generated from the official specs pinned in specs/ (source URLs, dates and SHA-256 in specs/SOURCES.json). Same credentials, same retries on 429 / 5xx (Retry-After honoured), JSON:API documents on the Apple side.

storebound api list --store apple --search "customerReviews"          # find an operation
storebound api apple apps_getCollection --param 'filter[bundleId]=com.example.app'
storebound api apple GET /v1/apps/123/appStoreVersions --all-pages      # METHOD path works too
storebound api play reviews.list --param packageName=com.example.app --all-pages --json
storebound api play POST /v1beta1/apps/com.example.app/crashRateMetricSet:query --body query.json
storebound api coverage                                                 # counts per API and resource, what commands wrap
  • GET runs right away (so do the Reporting API :query calls and other POSTs that only read).
  • Every write is a dry run by default: it prints the exact request (method, URL, body; the credential is never shown) and is only sent with --yes from an interactive terminal.
  • Owner-only operations (submit, release, delete, cancel, refunds, prices, testers and users, review replies, product page tests, Play edits.commit, app signing; the list is in cli/api/gate.ts) also ask you to type the operation id before anything is sent.
  • Agents read, never write: MCP has one tool for this, api_get (GET operations only). Under MCP or the desktop app no write goes out, whatever the flags.
  • Small on purpose: one table row per operation plus generic helpers (cli/api/), typed from the rows (path and required parameters, JSON:API request and response shapes). bun tools/gen-api.ts regenerates the tables and docs/api-coverage.md (every operation, its gate and the commands that already call it); CI fails when they are stale.

All docs · README