Product · March 2026 · 10 min read

How We Built the World's First Wine Trip API

Most wine travel sites are built the same way: a CMS, some editorial content, a map widget, and affiliate links to Booking.com. We built TheWineTrip differently. The API came first. The web UI came second. And we think this architectural decision will become a significant competitive advantage as LLMs get better at planning travel.

The Insight: Nobody Owns Structured Wine Travel Data

Wine trip planning involves two distinct problems that no existing tool solves together:

  1. Wine-specific knowledge — which estates to visit, what wines to taste, when to go, how to book
  2. Trip planning logic — routing between wineries, accommodation near the vineyards, day-by-day structure

General trip planners (Wanderlog, Layla, Google Trips) are wine-dumb. Wine apps (Vivino, Delectable) don't do trip planning. Wine Routes apps are regional and don't have APIs. Nobody offers structured wine travel data for consumption by developers or LLM agents.

That gap is what TheWineTrip fills — and the API is how we fill it at scale.

Architecture: API-First from Day One

We made an early decision: the API IS the product. The web UI is just one client. This meant:

  • Every feature ships as an API endpoint first
  • The web UI calls the same endpoints that external developers use
  • Affiliate URLs are baked into every API response — every consumer drives revenue
  • Zod schemas are the single source of truth — TypeScript types, API validation, and OpenAPI spec all derive from them
TheWineTrip API (/api/v1/*)
  ├── Our Web UI           (internal client, no rate limit)
  ├── MCP Server           (@thewinetrip/mcp-server)
  ├── OpenAPI 3.1 Spec     (/api/v1/openapi.json)
  └── Public API           (API key auth, rate-limited)

The Tech Stack

LayerTechnologyWhy
API frameworkNext.js 15 App RouterFile-system routing, edge runtime, Vercel deploy
Schema / validationZodSingle source of truth for types + OpenAPI
DatabaseSupabase (PostgreSQL)45K winery records, PostGIS for geo queries
Geo queriesPostGIS + ST_DWithinRadius search on GPS coordinates at scale
AI recommendationsAnthropic Claude SonnetStructured JSON output for itinerary generation
MCP server@modelcontextprotocol/sdkClaude Desktop + other LLM agent support
OpenAPI speczod-openapiAuto-generated from Zod schemas, always in sync
Rate limitingUpstash RedisPer-API-key request counting
HostingVercelGlobal edge, zero-config deploys

The MCP Server: Wine Data for LLM Agents

The most exciting distribution channel isn't our web UI — it's LLM agents. When someone asks Claude or ChatGPT to “plan a 5-day wine trip to Tuscany,” they should be able to call our API to get real winery data, geo routes, and booking links.

We shipped an MCP (Model Context Protocol) server that wraps our API with 6 tools:

// Tools available to Claude Desktop and other MCP clients
search_wineries       // Search by region, country, query string
get_wine_region       // Region details: grapes, airports, costs, best months
list_wine_regions     // All 5 MVP regions with winery counts
plan_wine_trip        // AI itinerary generation via Claude Sonnet
find_nearby_wineries  // PostGIS radius search
create_trip           // Save trip and get shareable URL

The agent workflow: Claude calls search_wineries to browse Tuscany estates, find_nearby_wineries to route between them, and create_trip to save the result as a shareable URL — all without touching the web UI.

Affiliate Revenue Built Into Every Response

Every API response includes affiliate URLs baked in — not as an afterthought, but as part of the schema:

{
  "data": {
    "id": "abc123",
    "name": "Antinori nel Chianti Classico",
    "latitude": 43.5588,
    "longitude": 11.2343,
    "description": "One of the oldest wine estates in Florence...",
    "booking_url": "https://www.booking.com/searchresults.html?ss=Chianti",
    "tour_url": "https://www.viator.com/searchResults/all?text=wine+tours+Tuscany",
    "guide_url": "https://winetravelguides.com/regions/tuscany"
  }
}

Every consumer of the API — whether it's our web UI, an LLM agent, or a third-party developer — automatically passes affiliate traffic through our links. This is the key monetisation insight: affiliate revenue scales with API usage, not just web traffic.

API Endpoints

MethodEndpointDescription
GET/api/v1/wineriesSearch 45K+ wineries with filters
GET/api/v1/wineries/:idSingle winery detail
GET/api/v1/wineries/nearbyPostGIS geo radius search
GET/api/v1/regionsAll wine regions with metadata
GET/api/v1/regions/:slugSingle region + airports, costs, grapes
POST/api/v1/tripsCreate + save a trip
POST/api/v1/recommendAI itinerary generation
GET/api/v1/openapi.jsonFull OpenAPI 3.1 spec

What's Next

We're expanding from 5 MVP regions to all 53 wine regions in our database — which means geocoding another ~42,000 wineries and running the same enrichment pipeline (OG scraping, Haiku description cleanup, Wikidata facts) at scale.

We're also adding user accounts (cloud-saved trips), a Stripe Pro tier for high-volume API access, and publishing the MCP server to npm so developers can install it with a single command.

The deeper goal: become the canonical wine travel data source that LLMs call when anyone asks about wine trips. We think that's a defensible position — and the API architecture puts us there.

Build with our API

Free tier: 100 requests/day. No credit card required. Full OpenAPI spec available.