Board Code Catalog

Every availability option carries two board codes:

Field	Meaning
boardCode	The normalized code, translated from the supplier's value into the catalog below.
providerBoardCode	The supplier's own code, exactly as we received it.

Read boardCode to group and filter by meal plan, and providerBoardCode when you need to tell apart two options that normalize to the same code.

Catalog

The codes are Spanish acronyms, because the normalized vocabulary predates the English API (SA = solo alojamiento, AD = alojamiento y desayuno, and so on). The Spanish column is included so the acronyms are readable, not because the API ever returns Spanish text.

Code	Name	Spanish régimen
SA	Room only	Solo alojamiento
AD	Bed and breakfast	Alojamiento y desayuno
DA	American breakfast	Desayuno americano
DC	Continental breakfast	Desayuno continental
DE	Scottish breakfast	Desayuno escocés
DI	English breakfast	Desayuno inglés
DIR	Irish breakfast	Desayuno irlandés
BR	Brunch	Brunch
SCO	Lunch only	Solo comida
SC	Dinner only	Solo cena
MP	Half board	Media pensión
MPZ	Half board with lunch	Media pensión con comida
MPB	Half board with drinks	Media pensión con bebidas
MPAV	Half board with water and wine	Media pensión con agua y vino
ML	Half board plus	Media pensión plus
PC	Full board	Pensión completa
PCB	Full board with drinks	Pensión completa con bebidas
PCAV	Full board with water and wine	Pensión completa con agua y vino
PCP	Full board plus	Pensión completa plus
TI	All inclusive	Todo incluido
TL	All inclusive soft	Todo incluido light
TP	All inclusive plus	Todo incluido plus
TR	All inclusive premium	Todo incluido premium
TII	All inclusive imperial	Todo incluido imperial
TO	All inclusive gold	Todo incluido gold
DSNEY	Disney meal plan	Plan de comidas Disney
DSNEYK	Disney quick service	Disney quick service

SC is dinner, not self catering

SC means dinner only. A supplier code of SC usually means self catering, and it normalizes to SA (room only). So a supplier's SC and our SC are different meal plans — always translate through the mapping instead of comparing the two strings.

Codes outside this table can still appear. The catalog also holds entries that reached it before anyone could name them, either harvested from a supplier we had no mapping for yet, or inherited from a legacy load: 1M, 2, ADMP, AM, DPLL, DT, FBFB, FROB, MDL, MPA, MPP, ON, SAG, SP, and TS. Treat them as opaque and fall back to boardName or providerBoardCode for display.

They stay unnamed because nobody has assigned an English description yet: some arrive on an availability response without a matching entry in that supplier's published board catalog (hobv2 DT / TS), others are legacy base codes that several providers still map into. Naming one means asking the supplier or reading their board content, not inferring from the letters — the same code means different plans across suppliers (TS is all inclusive plus for one connection and unknown for another). Numeric meal types are not opaque in the same way: a connection that publishes an ordinal table (for example 1331 breakfast through 1336 all inclusive) is named from that table and folded into this catalog.

Why several options share one code

The translation is many-to-one, and the collapse is heavy at the top of the table. Around 70 distinct supplier codes normalize to SA, and around 60 to AD. A single hotel can legitimately return several options that all read SA while differing in the supplier's own wording:

[
  { "boardCode": "SA", "providerBoardCode": "RO",   "boardName": "Room only" },
  { "boardCode": "SA", "providerBoardCode": "SC",   "boardName": "Self catering" },
  { "boardCode": "SA", "providerBoardCode": "RO12", "boardName": "Room only, no refund" }
]

This is expected: those are three different supplier products with the same meal plan. If your UI shows them as three identical rows, differentiate on providerBoardCode or boardName rather than on boardCode.

The vocabulary depends on the connection

Not every connection speaks the catalog above. Two modes are in use:

Mode	What boardCode contains	Connections
Normalized	Catalog codes (SA, AD, MP, …)	Most connections, resolved from the mapping database, plus mtx from a static list
Passthrough	The supplier's own code, untranslated	Connections configured to mirror codes, e.g. t10, stn

So RO and SA can both appear across connections and mean room only, and BB and AD can both mean bed and breakfast. If you aggregate across connections, normalize those pairs on your side until every connection is migrated.

On a passthrough connection, boardName is the reliable field: stn, for example, publishes over 500 boards with hotel-specific meanings (Half Board (Boxed Breakfast), Iftar, Full Board (Incl. Light Excursions)) that no catalog code captures without losing what the supplier actually sells. Read the code for filtering and grouping, and the name for display.

Filtering by board

resultFilters.boardCodes matches boardCode case-insensitively and falls back to providerBoardCode when the normalized code is empty, so a filter written against either vocabulary works:

{
  "criteria": {
    "resultFilters": {
      "boardCodes": ["AD", "MP"]
    }
  }
}

See Result filters for how it composes with the other filters.

Next Steps

• Boards Catalog - Query the boards a connection publishes
• Search Hotels - Filter availability by board