Developer docs

Build on top of Hatchable.

The SDK surface, the secrets architecture, and the full hatchable.toml reference. Written for people who'd rather read code than prose.

← User docs
Read this first — hard constraints Hatchable runs without a build step. Source files = production. No webpack/vite/esbuild/tsc/Babel; no JSX, .jsx, or .tsx; no ORMs (Drizzle, Prisma, etc.); no framework imports (Next, Remix, SvelteKit, Express). Each is a deploy-time anti-pattern reject. CSS/JS deps load from CDNs at runtime — Tailwind, Alpine, React via esm.sh + htm. Handler shape is fixed: export default async function (req, res) in every api/*.js file. Knowing these up front saves a lot of "why did the deploy reject this?" cycles.
Reference

SDK reference

Every module in the hatchable runtime, with worked examples and the full surface of each call.

  • db, knowledge, storage
  • auth, config
  • ai, scheduler
  • email, browser
 Architecture

Secrets & BYOK

The whole story behind [[secret]] manifests, the three tenancies, the platform setup gate, and how multi-tenant forks work.

  • Project / account / user tiers
  • Provider catalog & logical model aliases
  • The setup gate & gateway resolution
  • Multi-tenant fork pattern
  • Security model
 Reference

hatchable.toml

Every block, every field, every validation rule. Four worked examples covering personal tools, multi-tenant SaaS, LLM apps, and custom integrations.

  • Project metadata
  • [auth], [[cron]], [[fork.questions]]
  • [[secret]] (raw, ai)
  • Validation order
 Reference

MCP & tool surface

Connecting AI clients, the five-step build loop, prompting patterns, the 31-tool API surface with safety annotations, anti-patterns, troubleshooting.

  • OAuth + bearer token connections
  • The five-step build loop
  • 16 read-only / 16 destructive tools
  • Anti-patterns & troubleshooting

Common entry points