# Connector bindings A **connector binding** is the live link between a partner connector and a specific property, room or rate plan in your catalog. Bindings are what turn a curated mapping into a working channel — once they are active, partner messages flow through them automatically. ## What a binding does Mapping is the curation work — *this partner code corresponds to this catalog item.* A binding is the activation — *use that mapping for this property, on this connector, for this direction (in or out).* For a property to publish to a partner (or ingest from one), the property needs: * An **active connector** in your **organization** (the isolated workspace that holds your users, content, contracts and credentials — data in one organization is invisible from another, which is what makes white-label deployments independent). * **Credentials** for that connector, vaulted in your organization. * A **binding row** that says "this property goes through this connector". * The **mapping** between your catalog and the partner's vocabulary. The first three live on the property's *Channels* tab. The mapping lives on the curation pages. Together, they make the binding work. ## What you see as an operator Open a property and click *Channels*. You see, per channel: * **Status** — active, paused, pending mapping, error. * **Remote identifier** — the code the partner uses to address this property. * **Last activity** — last successful inbound or outbound message, with timestamp. * **Mapping completeness** — whether room, rate, attribute and meal-plan mappings are fully resolved or whether gaps remain. * **Recent messages** — a short list of what came in or went out, useful for spotting issues. Bindings can be paused without losing the curation work behind them — useful when you want to temporarily stop publishing a property to a partner but expect to resume. ## How a partner message lands at runtime When a partner sends a message — a rate update, an inventory change, a stop-sale, a booking — the platform needs to figure out, very quickly, which catalog item the message refers to. The chain: 1. The partner message arrives with the partner's identifiers (their property ID, their room code, their rate code, their meal plan code). 2. The bindings and mappings for that connector are looked up. 3. Each partner identifier resolves to your catalog item — property, room, rate plan, meal plan. 4. The message lands on the right item. If any identifier in the message has no mapping, the message does not vanish — it is held in a curation queue with the unmapped value visible, and you get a nudge to close the gap. As soon as you do, the queue drains and the next messages flow without staging. ## How outbound bindings work Outbound is the same shape, in reverse: 1. You change a rate, inventory cell, or restriction in Adrasis. 2. The channels that publish that property are identified via the bindings. 3. For each channel, your catalog item is translated into the partner's vocabulary using the mapping, any per-channel filters (rate-plan exposure, restriction overlays) are applied, and the outbound message is sent. 4. The partner accepts or rejects; the outcome is recorded on the binding's status. Bindings on the outbound side are also where per-channel exposure is honored: a rate plan you marked as "internal only" simply does not get included in the outbound message for any binding it is not exposed to. The same lever lets you publish a new package to your direct site only, sit with it for a week, then expose it to OTAs and metasearch once you are happy with how it sells. ## Why bindings need to be fast The busiest paths in the platform run through bindings. Every inbound rate update from a partner, every metasearch poll, every booking confirmation reads through a binding to translate identifiers. If that resolution is slow, partner traffic backs up and outbound feeds fall behind. Resolved bindings are kept fast where channel traffic needs them, and refreshed as bindings change. You do not see the mechanics; you see that bindings work fast and stay fresh. ## When a binding goes wrong A binding can be unhealthy for a few honest reasons: * **Credentials expired** — the partner rotated their secret and the new one was not entered. The binding's status flags this. * **Mapping gap** — a partner code arrived without a match. The message goes into the curation queue and the gap surfaces on the property. * **Partner connection down** — the partner connection is failing; the binding's recent-activity feed shows the failures. * **Partner format changed** — the partner changed what it sends or expects; this is escalated to the Adrasis team. In every case the binding stays paused-but-recoverable. Nothing is silently dropped; nothing is silently created. You see the issue, you fix it, the binding recovers. ## Binding history Every binding action — activation, pause, mapping update, credential change — appears in the binding history. When you need to answer "where did this rate come from", start from the binding and follow the related channel message. For the rate-cell-level history, see [Cell history](/console/pricing-and-availability/cell-history.md). ## Where to next * **The shared record bindings resolve into** → [Canonical mapping](/console/mapping-and-curation/canonical-mapping.md) * **Reconciling room types** → [Room mapping](/console/mapping-and-curation/room-mapping.md) * **Reconciling amenities and categories** → [Attribute mapping](/console/mapping-and-curation/attribute-mapping.md) * **Reconciling meal-plan codes** → [Meal plan mapping](/console/mapping-and-curation/meal-plan-mapping.md) * **The channel configuration model bindings live in** → [Channels](/console/distribution/channels.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/connector-bindings.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.