Delicious

API & Agents

Preview. The API and MCP server are in design — the shapes on these pages are what we're building toward, not a live endpoint yet. They're published so the surface is reviewable. Today the pipeline runs through the CLI and console.

The API lets three kinds of caller drive Delicious: the console at app.delicious.works, agents (via the MCP server), and third-party builders piping their output through to ship.

The core idea: a run

A run is one idea → accepted app execution — a state machine over the ten stages with the three human gates. Runs are long-lived and async (minutes to hours, plus App Review), so the API is built around: create a run → observe it (poll, webhook, or stream) → resolve its gates → fetch its artifacts.

A run's status is one of queued, running, awaiting_gate, paused, succeeded, failed, or cancelled.

Two modes

  • idea — the full arc. Submit an idea brief; the pipeline does discovery → spec → brand → build → QA → ASO → submit, pausing at the three gates.
  • ship — bring an already-built app (a repo or App Spec from any tool) and run only the last mile: QA, the Deliciousness Gate, compliance pre-flight, screenshots, metadata, signing, and submission. No native builder offers this as an API — it's the wedge.

Auth

  • Programmatic: a Bearer API key, minted in the console, with scopes (runs:read, runs:write, gates:write, artifacts:read, apps:read). A separate test key hits a sandbox that stops before real submission.
  • The credential tollbooth: your Apple App Store Connect key + signing identity are connected once in the console and stored encrypted server-side. Signing and submission happen on our infra — the API never returns them, and a run can only target an Apple account you've connected.

Next