Sell your supply
to partners and platforms.

Adrasis Console takes supply in from hotels, channel managers and bedbanks, and sells it on to OTAs, metasearch engines, partner agencies and your own API clients. Every channel works from the same product record, with the access and pricing you set per channel and partner.

What B2B means in travel.

B2B in travel means selling travel products to other businesses, such as agencies, online sellers and booking platforms, rather than to the traveler directly.

A hotel sells a room to a guest. A B2B seller stands one step back: it contracts or buys supply, prices it and sells it to another business that serves the traveler. That business might be a partner agency booking from its own login, an online travel agency listing your rates, a metasearch engine comparing prices, or a platform calling your API.

Net rates, markups and who sees which price

Most of the work is commercial. Supply arrives either at a net rate that you mark up, or at a selling price that pays you a commission. You then decide which partner sees which price. A partner should see what it pays, and nothing of the cost and margin behind it.

The guide What is B2B in travel? explains these terms in more depth. The rest of this page shows how Adrasis runs the distribution side.

Supply in, channels out.

Distribution in the Console runs in two directions. Supply comes in from outside sources, and approved supply goes out to the channels that sell it. Both directions share one product record.

Direction What moves Who is on the other side
Inbound Property content, rates, inventory and restrictions, plus bookings where a partner sends them Hotels, channel managers, bedbanks and content sources
Outbound Availability, rate and inventory updates, booking acknowledgments, content updates and the rate plans each channel may show OTAs, metasearch engines, B2B partners and consumer travel apps

One record, with the source on every cell

A rate your team types in and a rate sent by a channel manager land in the same place and behave the same way. Every rate and inventory cell records which source last wrote it and when, so any price can be traced back to the partner that sent it. A markup added before publishing is one pricing rule, not two calculations your team has to keep in step.

Nothing fails silently

When a channel write fails, it goes through a retry chain. If it keeps failing, it moves to a holding area where it can be replayed or investigated, and the Console marks it as needing attention. The same status view shows each channel's recent success rate, its last credential check and any open mapping gaps.

Give each partner its own account and catalog.

A technical partner that connects to your supply gets a partner account. You decide which properties it can discover, and you issue the credentials it signs in with.

Partner accounts live in the Console under Partner Network. Create one account for each technical partner relationship. The account is the fixed boundary for authentication, the properties published to that partner, its booking references and reconciliation.

Profiles and the Channel Portfolio

Every account starts with a Default profile. Its Channel Portfolio, the list of properties open to that profile, begins as a snapshot of the accommodation properties published at that moment. It is not an “all properties” rule: a property you publish later stays closed to the partner until you open it.

When the same partner needs a different catalog for a different audience, add another profile. A new profile starts empty, and profiles may share properties. You can open or close a single property or a selected group, or build a list from country or place filters and review the matches before opening them. Closing a property removes it from that profile's results only. The property is not deleted and stays open in other profiles.

Credentials belong to the account

One account can hold several named credentials, for example production, certification and disaster recovery. A credential is never tied to a profile: the partner chooses the profile in its request, and the Default profile applies when it does not. Give every partner account its own credentials, so audit, revocation and usage records stay separate.

  • OAuth 2.0, recommended for new integrations. The partner exchanges a client ID and secret for a short-lived access token.
  • HTTP Basic, for older integrations that need a fixed username and password.
  • API key, for simple machine-to-machine clients that send one long-lived key.
Scope What it allows
distribution:read Reference data, the selected profile's property catalog, accommodation availability and offer search.
distribution:booking Prebook, book, booking reads across the account, cancellation quotes and cancellation, booking webhooks, and every transfer, tour, flight, package and trip call, searches included.

New credentials receive both scopes by default. An integration that must never create or cancel a booking should get distribution:read only.

Credentials are managed from the account's API Access tab, and the secret is shown once, at creation or rotation. Rotate replaces the secret and keeps the credential, disable refuses sign-in until you turn it back on, and revoke ends the credential for good. A disabled or revoked credential stops working, along with the tokens issued from it, once the change propagates.

The Partner Network documentation includes an operator checklist for bringing on a new partner.

How partners book through the API.

The Distribution Partner API is one REST contract with JSON bodies. Hotels, vacation rentals, villas and apartments all go through the same flow, so a partner does not need separate code for each property type.

Every request goes to one base URL over HTTPS. The access token identifies the partner account, so a request needs no extra account header.

https://ari.console.adrasis.com/api/v1

Before it searches, the partner builds its own copy of your catalog, with descriptions, photos, room types, location and policies, and keeps it current with delta updates. From there, the booking flow has four steps.

  1. Search

    Bulk search compares 1 to 100 properties in one request and returns the lowest-priced available option for each. Detail search lists up to twenty options for one property.

  2. Prebook

    The chosen option is checked against current availability, and its price and cancellation policy are fixed behind a token that lasts 30 minutes. If the price moved, the partner sees the new one first.

  3. Book

    The booking is created and inventory goes down. A mandatory Idempotency-Key means a retry after a timeout returns the original booking instead of creating a second one.

  4. Cancel

    The partner first asks for a cancellation quote, which shows the fee and changes nothing, then confirms the cancellation.

Following a booking after it is made

The partner can read a booking back at any time, which matters while it is still resolving, for example a request-to-book rate waiting for the property's acceptance. Instead of polling, it can register an HTTPS endpoint for signed booking events such as created, confirmed, modified and canceled. For reconciliation, bookings can be looked up by the partner's own reference, which is unique across its account, or by creation date, stay date or recent changes.

Transfers, tours, charter flights and packages

Transfers, tours and charter flights follow the same search, prebook and book rhythm on their own paths. A package combines 2 to 5 selected services of at least two kinds, such as a hotel stay and an airport transfer, into one booking with one inclusive price: every service confirms, or none does. A trip is lighter. It groups bookings that are already confirmed into one itinerary, and each booking keeps its own price, policy and lifecycle.

Build and certify on the same host

Integration, certification and live traffic all use the same host, and there is no separate sandbox. Pilot credentials see a demonstration catalog with rates and availability generated for testing, and test bookings do not touch real allotment or create charges. When an OAuth credential is promoted to live supply, its client ID, base URL and flow stay the same. Only the catalog it reaches changes.

Building an AI agent? The same contract is also available as a Model Context Protocol (MCP) server, with the same authentication and usage rules. See the MCP server page, or start with the developer guide for a first authenticated call.

Publishing to metasearch and B2B platforms.

Metasearch engines and large B2B platforms send many requests per second and compete on speed: a result that takes 800 ms loses to one that takes 80 ms. Adrasis handles each partner's format and timing.

These channels only read: you publish availability, rates and inventory, and the partner never writes back into your inventory. Setup is the same as for any other connector. Activate it, add your credentials, bind the properties that belong in the feed and review how your rooms, rate plans and meal plans map to the partner's codes. The partners available to your organization are listed in the Console under Connectors.

Choose which rate plans each channel shows

Visibility is set per channel. A members-only rate plan can stay off a metasearch engine, while a plan such as Non-Refundable Europe is the one the partner shows. The same per-channel rule decides what appears in every other feed.

Where the bookings go

These channels display your rates and pass the click on. Either the traveler books in the partner's own booking flow and the booking reaches Adrasis through a path agreed with that partner, or the click goes to your own booking site and becomes a regular direct booking. In both cases your normal booking screens handle it, and the channel page shows whether the feed is healthy and when the partner last polled.

Supply from bedbanks and channel managers.

Distribution starts with supply. Next to your own contracts, Adrasis takes inventory from bedbanks and live rates from channel managers, and each partner's connector deals with that partner's format.

Bedbanks: net rates plus your markup

A bedbank is a B2B network that resells hotel inventory. With Adrasis you buy from it: its catalog, rates and inventory come in, you add your markup, and you decide how that supply is priced and which markets it reaches in your own channels. Bedbank rates are net, and the pricing engine applies that policy on its own, so there is no net or commission setting to make per connection.

Bookings on bedbank inventory are confirmed against the bedbank's inventory and handled on a separate buyer-side screen, because settlement, cancellation and liability follow the bedbank contract rather than your direct-property rules. The guide What is a bedbank? covers the model in full.

Channel managers: one connected source per property

When a hotel already works with a channel manager, you connect to that channel manager and receive its rate and availability changes through one connection. A property has one connected channel at a time, so two feeds never compete for the same cells. Prices that arrive this way are read-only in the Console and are corrected at the channel manager.

What an XML integration usually means

When travel companies ask for an XML integration, they usually mean exactly these supplier connections, where a channel manager, bedbank or hotel system exchanges rates, availability and bookings in its own message format. In Adrasis, each partner's connector handles that format, and your team works from the same product record whatever format the partner uses.

Partner agencies without an integration.

Not every partner has developers. With Sales & Distribution, another agency sells your products from its own Console login, with no API work and no shared account.

You add the agency, choose the market it sells from and the currency of the relationship, and activate the destinations it may sell. Access is closed by default, so a destination you do not activate stays invisible to that partner. Pricing rules by market, agency or product set what the partner pays, and a minimum selling price lifts an over-discounted price back to the floor instead of losing the sale.

The partner sees one payable price, never your source amount, commission or markup, and the retail markup it adds for its own customers stays private from you. Every booking is recorded under your organization with the partnership attached, so both sides can report the sale.

An agency that partners with several organizations searches all of them at once, each line priced under its own partnership. The same partnerships work over the API too: when the agency connects with its own API credentials, its partnerships and pricing apply automatically to every search and booking.

The travel agencies page walks through the partner setup step by step.

Request limits and provider fees.

Partner traffic grows with your network. Request limits are part of each connection's agreed terms, and you review them with your Adrasis contact before traffic increases.

The connection terms name the operations covered, the request count or rate, the account scope and the time window. Several operations can share one account allowance, and adding credentials or profiles does not create a new allowance.

Insights shows observed requests, channel errors and traffic trends. When you plan a new partner, share the period, the channels involved and the expected increase with your Adrasis contact, who reviews the change against your terms. Looking at Insights does not change a limit on its own.

Provider fees. Suppliers, channel managers, metasearch engines and other distribution channels charge their own fees under their own agreements and set their own request limits. Those fees are not part of Adrasis pricing, and an Adrasis capacity change does not change a provider's limits. See pricing for the Adrasis plans.

See it with your own partners.

Try the Console free, or tell us about your channels, partners and API plans and we will show you where Adrasis fits. Plans are priced per organization, not per user.