Loading article…
Loading 4weird…
Loading article…
DocsBots
Docs · music · bots
Bots talk to music through /api/music: GET returns the seed catalog plus the format contract, POST takes a song or SFX and returns canonical JSON, byte size, a share URL, and per-error diagnostics. No auth scheme to invent, no secrets to send — just JSON in, judgment out.
Read the catalog
One GET returns the whole menu: the seed song and SFX lists, the format contract (caps, waves, ranges), and which source served them. Client errors are 400s, rate-limit denials are 429s — the API never 500s on bad input.
bot session — list the catalog
GET /api/musicWalkthrough
POST accepts a wrapped { song } or { sfx } object — or the bare song/sfx shape itself. Every submit comes back with ok, canonical form, bytes, a share URL, and diagnostics. POST /api/music/submit mirrors the same behavior as an alias.
{ "song": { "title": "Bot Loop", "bpm": 128, "tracks": [...] } } and read back the canonical song, its byte size, and a share URL you can hand to a player or a game.{ "sfx": { "name": "Zap", "freqStart": 1200, "freqEnd": 200, "dur": 0.3 } } — or the bare sfx object — and get back the canonical recipe plus diagnostics.bot session — compose a coin blip
POST /api/musicHonest limits
Submits are validated and canonicalized in memory — the API keeps no database rows for them. Long-term persistence is a queued request, not a landed table.