Marketing Rewrite, Schema-Driven API Docs & Invoice API Fix

Marketing Site Rewrite

The homepage and features page now reflect what SpeyBooks actually ships — not what’s planned.

Homepage

• Hero copy rewritten — removed references to unshipped features (CLI, MTD submission, SDK libraries). The hero now leads with what’s real: double-entry ledger, invoicing, bank reconciliation, and a typed REST API.
• Features grid replaced — the six-card grid previously showed four planned features and one incorrectly marked as available. All six cards now show shipped, live capabilities: REST API with prefixed IDs, scoped API keys, immutable ledger, developer shell, auto-categorisation, and row-level security.
• Tech stack section — replaced “API libraries coming for Node/Python/Go” (none existed) with “Built with Fastify, React, PostgreSQL, TypeScript”.
• Pricing fix — removed “SQL” from “Full data export (SQL, CSV & API)” as SQL access is not yet available.

Features Page

• Four spotlight sections — API-first design, auto-categorisation, Ltd company support, and double-entry architecture each get a dedicated section with custom SVG illustrations.
• Fifteen-card feature grid — every card represents a shipped feature, badged as “Live”. Section title changed to “Production-ready from day one”.
• Copy refinements — headline updated to “Accounting as Code infrastructure developers enjoy using”, auto-categorisation reframed as “Categorisation you can audit, explain, and trust”, and trial language corrected (card required, 90-day for early access).

Schema-Driven API Documentation

API docs are now generated directly from the Zod validation schemas in the route files, eliminating drift between what the API accepts and what the docs describe.

Documentation Generator

• Single-command pipeline — pnpm run docs extracts schemas from route files, generates Docusaurus-compatible markdown, and rebuilds the documentation site.
• Two-source architecture — field names, types, required/optional, and constraints come from Zod schemas (always the source of truth). Descriptions, examples, and business rules come from context metadata files (written once, updated rarely).
• Missing field warnings — the generator reports any schema fields that lack descriptions, so new fields are never silently omitted from docs.

Resources Documented

Six core API resources now have accurate, schema-derived documentation:

• Invoices — 9 endpoints including create, update, status transitions, payments, email, and PDF download.
• Contacts — 6 endpoints including create, update, delete (with soft-delete for contacts with invoices), and financial summary.
• Transactions — 9 endpoints including create (with balance enforcement), status transitions, reconciliation, categorisation, and account ledger.
• Quotes — 7 endpoints including create, update, status transitions, and quote-to-invoice conversion.
• Accounts — 7 endpoints for chart of accounts management including hierarchy, balances, and account types.
• Organisation — 3 endpoints for company details and accounting settings.

Bug Fixes

• Invoice API: items vs lines — the API expects lines for line items but the documentation specified items. Documentation now matches the implementation.
• Invoice API: vatRate type — the API expects an integer (e.g., 20) but the documentation specified string values ("standard"). Documentation corrected.
• Invoice API: invoiceType undocumented — the invoiceType field is required on invoice creation but was completely missing from the documentation. Now documented with accepted values sales and purchase.

API Documentation Audit

A full audit of the API surface identified 99 public endpoints across 17 resources. The invoices documentation alone had 12 discrepancies with the implementation. The remaining 11 resources (categorisation rules, bank imports, API keys, reports, webhooks, directors, director loans, dividends, and supporting resources) are scheduled for Phase 2 documentation.