bymundi API

Itineraries

The block tree, block types, refs, and days that come from a trip's design.

The tree

A trip's itinerary is a tree of blocks. Read it with GET /v1/trips/{tripId}/itinerary; change it with POST /v1/trips/{tripId}/itinerary/ops, a list of ops applied together or not at all.

Block types are Spanish machine keys — keep them as they are:

Type What it is
capitulo A section at the root; holds content.
agenda The organizer that holds the days.
dia A day.
actividad A stop or activity in a day.
alojamiento A stay.
vuelo, transporte, tren, crucero Flights and transfers.
comida A meal.
texto A note.

Each type's data fields, as the apply ops operation accepts them:

data fields by block type — use exactly these names; an unknown field is refused. Rich-text fields accept plain text. catalogRef takes only an id a tool returned (search_catalog, search_places, suggest_routes), as {"kind":"punto","id":"…"}.

Ops

Four ops: add, update, move, delete. add and move place a block with parentId and position (start, end, after, before) plus anchorId for after/before. update needs the block's current version: if someone changed it since you read it, the op is refused rather than overwrite them. Give each add a clientId to find its new id in the answer's created.

Unknown fields are refused, not ignored, so a typo cannot silently misplace a block.

Days from a design

A trip can have a design: its route, as stops with nights and the transfers between them (hasDesignedRoute: true). On such a trip the days come from the design: adding or deleting dia blocks is refused. Change the design with PATCH /v1/trips/{tripId}, then call POST /v1/trips/{tripId}/itinerary/sync to rebuild the days.

Refs (MCP)

Over MCP, get_itinerary gives every block a short ref, and tools accept refs or full ids, so a model never has to copy long ids. An ambiguous ref answers ambiguous_ref.

Operations