# Room mapping
Rooms are the unit you sell. They are also the thing partners describe most differently — every channel manager, every bedbank, every metasearch engine has its own way of naming them. **Room mapping** is what turns that diversity into one canonical room you can curate, price, and distribute consistently.
## What a room mapping does
Each canonical room — say *Deluxe Sea View, Double Occupancy* — is matched against the way each source talks about the same room.
Many partner room codes resolve to one canonical room. Provenance is preserved per source.
Once mapped, a rate that comes in for *DBL-DLX-SV* lands on your *Deluxe Sea View* canonical row. A booking placed against the canonical row goes out as the right code to whichever channel needs it.
## What you map
A room mapping decides three things per source:
* **Which canonical room** this source's room corresponds to.
* **The remote identifier** the source uses for it (their code or ID).
* **Whether this binding is active** — you can pause a mapping without losing the curation work behind it.
You make this decision once per (canonical room, source) pair. The mapping persists; subsequent messages flow without further action from you.
## How mapping a new property usually goes
A typical mapping pass when onboarding a property through a new source:
1. **Open the property's mapping page.** The list shows every canonical room of yours and every room the source published.
2. **Adragent fills in the obvious matches.** When the names line up, the codes are recognized, or the capacities and types match cleanly, the agent suggests the mapping; you accept.
3. **Resolve the ambiguous matches.** Two source rooms look like they could both map to your *Deluxe Sea View*; you decide which one — capacity, amenities, recent bookings are shown alongside so the call is usually obvious.
4. **Handle the leftovers.** Rooms in the source that have no canonical match yet — typically because they are new room types you have not added to your catalog. You either add a canonical room and map it, or mark the source room as unmapped (it will not flow until you do).
For a property with eight rooms this is roughly five minutes. For a 200-room resort with twelve room types you batch — "match all rooms with 'Deluxe' in their name to my Deluxe canonical rooms" — and Adragent does most of the work on confirmation.
## When the mapping changes
Rooms evolve. The mapping surface is alive:
* **A source adds a new room type.** A push or pull from that source returns a code you have not mapped yet; you see it flagged; you map it.
* **A source renames or re-codes a room.** The new identifier surfaces on the curation page; you confirm the existing canonical mapping (or change it) so messages keep flowing.
* **You add a new canonical room.** Now the same source's room can be re-mapped to it if you decide that is a better fit.
* **You retire a canonical room.** Existing bookings keep their lineage; future mappings cannot target the retired row.
Every change is recorded — when, by whom, what was the previous mapping, what is the new one.
## Per-channel exposure
A canonical room can be mapped differently depending on the direction of the channel:
* **Inbound** — when a source sends rates or inventory for a room you have not curated, you decide which room it lands in (or whether to ignore it).
* **Outbound** — when you publish a canonical room out to a channel, the partner's room code goes in the outgoing message; the partner sees their room name, not yours.
This is also where you control which canonical rooms go to which channels. A "staff-only" or "internal demo" canonical room never has to map to any outbound channel — useful when you want to test a new packaged room (BAR + spa credit) on your direct site for a couple of weeks before exposing it to OTAs and metasearch.
## What about room-level details
Mapping is about the *identity* of the room — *which room*. The *content* of the room (description, images, in-room amenities, capacity, layout) lives on the canonical record itself. Once mapped, the source can keep contributing content (new images, updated descriptions in new languages); the canonical record absorbs the additions, with provenance.
For amenities and other typed features, see [Attribute mapping](/console/mapping-and-curation/attribute-mapping.md).
## Where to next
* **Reconciling amenity and feature codes** → [Attribute mapping](/console/mapping-and-curation/attribute-mapping.md)
* **Reconciling meal-plan codes** → [Meal plan mapping](/console/mapping-and-curation/meal-plan-mapping.md)
* **What happens when a partner sends a room-level message at runtime** → [Connector bindings](/console/mapping-and-curation/connector-bindings.md)
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://adrasis.gitbook.io/console/mapping-and-curation/room-mapping.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.