Open JSON interchange format for complete travel itineraries

One trip, one JSON file.

Roadbook describes an entire trip — itinerary, transport, bookings, tickets, activities, travelers and logistics — in one portable .roadbook.json document that humans, travel apps and AI assistants can read and write. Open, versioned, vendor-neutral, MIT licensed.

Generate with AI → See an example Read the specification Validate a Roadbook

A common language for travel itineraries#

A trip rarely lives in one place. The plan is in an e-mail thread, the flights in an airline app, the hotel in a PDF confirmation, the museum slots in a calendar, the train tickets in another app, the budget in a spreadsheet and the agency's program in a Word document. None of these speak to each other, and none of them can be handed to another application — or to an AI assistant — as a whole.

Roadbook is a travel itinerary format that puts the entire trip into one structured, machine-readable document: the day-by-day schedule, the transport legs, the bookings and their references, the scannable tickets, the travelers and their roles, the alternatives when it rains, the checklists and the emergency contacts. Because it is plain JSON with a published schema, the same file can be produced by a travel agency's system, a script, or an AI travel planner — and consumed by any player, importer or analytics tool that implements the specification. That is what makes it an itinerary interchange format rather than yet another app's internal data.

• Portable — one self-contained file you can e-mail, store, version or import elsewhere.
• Structured — typed items, explicit references between days, bookings, tickets, people and vehicles.
• Machine-readable — JSON Schema, English enum tokens, ISO dates and times, integrity rules checked by a validator.
• AI-friendly — small enough to fit in a model's context; generated, validated and repaired in a loop.
• Vendor-neutral — an open specification; no registration, API key or permission is required to implement it.

One format, every kind of trip#

Roadbook is transverse: it is not tied to a travel style, a vendor or a distribution channel. The same schema, the same players.

What it looks like#

{
  "formatVersion": "1.2",
  "id": "bruges-weekend",
  "name": "Weekend in Bruges",
  "start": "2026-09-12",
  "end": "2026-09-13",
  "members": [
    { "id": "m1", "name": "Alex", "role": "owner", "kind": "adult" }
  ],
  "days": [
    {
      "id": "d1", "index": 1, "date": "2026-09-12",
      "title": "Canals and belfry",
      "items": [
        { "id": "i1", "time": "10:00", "title": "Canal boat tour",
          "type": "boat", "status": "planned",
          "place": "Huidenvettersplein, Bruges",
          "alternatives": [
            { "id": "a1", "trigger": "rain",
              "title": "Groeninge Museum instead" }
          ] },
        { "id": "i2", "time": "12:30", "title": "Lunch",
          "type": "meal", "status": "planned",
          "options": [
            { "id": "o1", "title": "De Halve Maan", "place": "Walplein 26" },
            { "id": "o2", "title": "That's Toast", "place": "Dweersstraat 4" }
          ] }
      ]
    }
  ]
}

More: nine annotated examples — minimal, city break, family vacation, business trip, road trip, multi-city, agency package, flight + hotel, full-featured demo — all validated against the current schema. Preview the demo →

Quickstart#

Why not iCal, GPX or a PDF?#

Those formats solve different problems and Roadbook does not replace them: an iCalendar export of a Roadbook, or a GPX track of a driving day, complement it well. What they cannot do is carry the whole trip with its semantics.

Read more: what a travel itinerary format needs · itinerary interchange between applications.

An open specification, independent of any application#

Roadbook Format is the open specification. The official player roadbook.plus is one implementation, used to validate the spec on real trips; the validator is the reference implementation of the integrity rules. The three are deliberately kept separate.

Specification status#

Ecosystem#

Around the specification: players (the official player roadbook.plus — offline-first PWA, details — and compatible viewers, yours included), generators (scripts, AI assistants, agency tooling), validation (web, CLI, ESM library, npm package in preparation) and agent tooling (llms.txt, llms-full.txt, MCP — planned). See integrations.

FAQ#

Is it free?

Yes — specification, schema, validator and examples are MIT licensed. Build a player, a generator or a commercial product on top of it. No API key, no account.

What is a Roadbook file, in one sentence?

A single .roadbook.json document describing a complete travel itinerary — schedule, transport, bookings, tickets, travelers, alternatives, checklists, logistics — with a declared formatVersion and a public JSON Schema.

Can an AI assistant generate one?

Yes. Plain JSON, English tokens, public spec: any capable model can produce a file, and the validator's path + message errors are made to be pasted back for correction. How →

Where do images and PDFs live?

Outside the file: image and voucher fields are URLs (or data-URLs for tiny assets). The JSON stays small enough to fit in an LLM context or a sync payload.

Are the tickets real?

Yes — a ticket carries its actual encoded payload and barcode format; a player renders a scannable code from it, offline.

Can I add my own fields?

Yes. Readers must ignore — and preserve — unknown fields. Prefix vendor extensions (e.g. x-myapp-…) to avoid future collisions.

Is Roadbook tied to the official player?

No. The player is one implementation; the format is an open specification anyone can implement.

Is there a machine-readable summary for AI tools?

/llms.txt (concise) and /llms-full.txt (self-contained summary of the spec) list the canonical URLs and generation rules.