Zest

An AI operations team for restaurants that sell on Zomato, Swiggy and dine-in. A web app plus a conversational copilot that can act on the owner's behalf, with every change held for the owner's approval. Product plan: PLAN.md.

Run it

npm install
cp .env.example .env.local     # optional: add ANTHROPIC_API_KEY for the full copilot
npm run dev                    # http://localhost:3000

The first request creates .data/zest.db and seeds a sample restaurant (Rasoi 27). "Look around with sample data" opens it; "Get started" creates your own restaurant in the same database.

For a production build: npm run build && npm start. Production needs ZEST_SECRET_KEY, and keeps the sample restaurant read-only unless ZEST_DEMO_WRITABLE=1.

To try a real MCP connection locally:

node scripts/mock-partner-mcp.mjs     # a stand-in partner MCP server on :8787

Then in Connections pick a platform → "MCP server" → http://localhost:8787/mcp. Approving a menu change calls its tools; http://localhost:8787/log shows what it received.

Deploy (Vercel + Turso)

The pages and the API are one Next.js app, so one Vercel project serves both. The database lives on Turso (hosted SQLite).

1. Database. In Turso, create a database (pick the Mumbai region). Copy its URL (libsql://…) and create a token.

2. Project. In Vercel, import this GitHub repository. Framework is detected as Next.js; leave the build settings as they are.

3. Environment variables (Project → Settings → Environment Variables, then redeploy):

   Name	Value
   DATABASE_URL	the Turso URL
   DATABASE_AUTH_TOKEN	the Turso token
   ZEST_SECRET_KEY	output of node -e "console.log(require('crypto').randomBytes(32).toString('base64'))". Keep it safe: changing it makes stored platform credentials unreadable.
   ANTHROPIC_API_KEY	optional, for the full copilot and document reading
   ZEST_DEMO_WRITABLE	optional, 1 to let visitors change the sample restaurant

4. Open the deployment URL. The first request creates the tables and the sample restaurant.

Without DATABASE_URL the app still starts on Vercel, but on a temporary database that resets whenever the server restarts.

Other hosts. Dockerfile builds a self-contained server (data on /data), and render.yaml is a Render blueprint with a persistent disk.

How it works

Browser (Next.js pages)  ──►  /api/* route handlers  ──►  lib/server/*
                                                           ├─ db.ts, schema.ts      libSQL/SQLite via Drizzle
                                                           ├─ copilot.ts            Claude tool runner + keyword fallback
                                                           ├─ approvals.ts          draft → approve → execute → audit
                                                           ├─ connectors.ts         sandbox | MCP | partner API | partner-app sign-in
                                                           ├─ ingest.ts             payout emails (rules, Claude fallback)
                                                           ├─ vision.ts             documents and menu photos (Claude vision)
                                                           ├─ whatsapp.ts           Meta Cloud API, outbox
                                                           └─ crypto.ts, session.ts encrypted credentials, signed cookie

Nothing reaches a platform without the owner. Agents and the menu editor create approvals. Approving one runs it through each live platform's connector and records every step (and any failure, per platform) in the audit log. Menu changes can be undone; posted replies and disputes can't.

Connectors. Every platform implements one interface (setAvailability, setPrice, updateItem, replyToReview, raiseDispute, createPromo, listOrders):

Method	Status
MCP server	Works. Verified on connect by listing tools; actions call the server's tools.
Partner API	Adapter in place; paths are placeholders until partner API access and specs are available. Saved keys show as "pending" until *_PARTNER_API_URL is set.
Partner-app sign-in	Credentials are stored encrypted. The browser worker that signs in and acts on the partner portal is the next build step; until then actions report that clearly.
Sandbox	Used by the sample restaurant. Mirrors actions locally.

Copilot. With ANTHROPIC_API_KEY, the copilot runs Claude (claude-opus-5-5, server-side refusal fallback on) with nine tools: five that read the database (sales, orders, payouts, reviews, menu) and four that draft approvals (menu change, review reply, dispute, promo). Without a key it answers from the same data with keyword rules. Conversations are stored per restaurant.

Zomato and Swiggy listings. When an owner pastes their Zomato link (full or zoma.to share link) or Swiggy link, Zest reads it (Zomato: the public page and order page; Swiggy: the menu API its mobile site uses), fills in their profile, saves the rating and details, and brings in the menu with photos. The first read of a platform imports the menu if there is none, or sets that platform's prices and stock on dishes with the same name, adds the rest for that platform only, and marks dishes the listing doesn't have as off on that platform. Reading again (Connections) refreshes rating and details but never the menu. Results are cached for 10 minutes per link. Zomato blocks data-centre IPs, Vercel's included, so production needs LISTING_FETCH_VIA, a scraping relay URL template (see .env.example); without it the owner fills the form in by hand.

This is the beginning of the README. Read the rest at the original. Read the full README ↗