# Inventory **Inventory** is the count of bookable units — how many of a particular room are sellable on a particular date. It is the other half of pricing: a room without inventory is a room you can advertise but not sell. ## What inventory looks like Per room, per date, the platform tracks: * **Total inventory** — the cap on bookable units for the date. * **Already booked** — units committed to existing bookings. * **Available** — what is left to sell. * **Allotted vs. on-request** — units pre-allocated under a contract vs. units you request from the supplier as bookings come in. The console shows this as a calendar grid: rows are rooms, columns are dates, cells show "*available / total*" with colour coding. ## Where inventory comes from For your own properties, inventory is what you set — directly, through Adragent, or through bulk operations. For inventory you ingest from suppliers (channel managers, bedbanks, content sources), the partner sends updates and the platform applies them to your canonical inventory rows. Either way, the canonical inventory row is one source of truth. Channels you publish to — outbound — read from it. Bookings — direct or through a partner — decrement from it. ## Allotments — pre-allocated commitments A contract often pre-allocates inventory: *the supplier will hold 5 rooms per night for us in May–September, with a release period of 7 days*. That is an **allotment**. Allotments work differently from open inventory: | Concept | Behavior | | ------------------- | ---------------------------------------------------------- | | **Total allotment** | The maximum the supplier will hold for you. | | **Used** | The number sold within the allotment. | | **Unused** | What is left of the allotment for the date. | | **Release period** | The cut-off when unused inventory returns to the supplier. | Beyond the allotment, you may have access to **on-request** inventory — units you can request from the supplier as bookings come in, subject to confirmation. The platform can mix both pools per date. ## Setting inventory across dates The inventory calendar lets you: * **Apply a fixed count** — *5 rooms per night for May.* * **Vary by day** — *5 rooms weekdays, 8 rooms weekends.* * **Hold back inventory for a market** — *Reserve 2 rooms per night for direct bookings; release the rest to channels.* * **Sync with a supplier feed** — when a partner pushes updates, the platform applies them to the canonical row automatically. * **Bulk-edit through Adragent** — *"Increase Hotel Sunrise's Deluxe Sea View inventory to 8 per night for all weekends in June."* Every change goes through preview before commit; the cell history records the change. ## When inventory runs low The platform surfaces low-inventory situations explicitly: * **Cell-level warnings** in the calendar grid — colours shift as availability drops. * **Organization-level summaries** — properties with sold-out dates in the next 30 days, dates with high pace. * **Channel-level signals** — a partner asking for a date that is sold out gets a clean *no inventory* response, not a stale yes. You decide how to react: open an extra room, top up an allotment, raise rates, close the date, route bookings to a different property. ## Shared inventory across rate plans A single room's inventory is shared across all the rate plans that sell it. A *Deluxe Sea View* with 5 rooms available on a date can be booked under any rate plan published for it — the first booking in (whichever rate plan it lands under) decrements the same available count. This is what keeps overbooking from rate-plan multiplication: one inventory pool serves many rate plans, not the other way around. ## How inventory plays with restrictions Inventory is *how many*; restrictions are *under what conditions*. You can have 5 rooms available on a date but a 3-night minimum stay restriction; a single-night booking is not allowed even though the inventory exists. Restrictions and inventory together determine whether a specific booking can land. See [Stop-sale & restrictions](/console/pricing-and-availability/stop-sale-restrictions.md). ## Per-channel inventory exposure Like rate plans, inventory can be exposed differently per channel: * A property might publish all available inventory to one channel and only a portion to another (a market reserve). * Inventory committed to a B2B contract may be invisible to retail channels. * A property running an internal demo might have inventory marked direct-only. The mechanism is the same per-channel restriction overlay used everywhere — see [Stop-sale & restrictions](/console/pricing-and-availability/stop-sale-restrictions.md). ## Bookings, in and out Bookings move inventory: * **A direct booking** decrements the canonical inventory row. * **A channel-sourced booking** (e.g. through a metasearch redirect) decrements the same canonical row. * **A booking on third-party inventory** (e.g. bedbank supply you resell) decrements the supplier's inventory through the buyer-side flow, not your own canonical inventory. * **A cancellation** restores inventory. Every booking has a trace from the cell back through the channel that produced it, with timestamps. This is what makes overbooking debuggable. ## Adragent and inventory Common operator phrases that map to Adragent inventory operations: * *"Set Hotel Sunrise's Deluxe Sea View to 5 rooms per night for May 15 to June 15."* * *"Hold back 2 rooms per night for direct bookings on all the Antalya properties for the summer."* * *"Show me every property with sold-out dates in the next 7 days."* * *"Increase the allotment from supplier X for property Y by 3 rooms per night."* All write operations preview before applying. ## Where to next * **The pricing arrangements that read from inventory** → [Rate plans](/console/pricing-and-availability/rate-plans.md) * **What controls bookability on a date beyond just availability** → [Stop-sale & restrictions](/console/pricing-and-availability/stop-sale-restrictions.md) * **The per-cell history surface for inventory changes** → [Cell history](/console/pricing-and-availability/cell-history.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/pricing-and-availability/inventory.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.