> This page is for API Reference.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.navipartner.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.navipartner.com/_mcp/server.

# Introduction to Availability

The Availability API answers the question *"when is something happening, is it available, and at
what price?"*. Three endpoints serve that question at different shapes:

| If you want…                                                                             | Use                                    | Notes                                                                                                       |
| ---------------------------------------------------------------------------------------- | -------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| At-checkout, single-date check with **personalized** price and authoritative capacity    | [`getCapacity`](./getCapacity)         | Accepts `customerNumber`. Run this at point-of-purchase before reserving.                                   |
| Date-range calendar for an item, with **indicative** price and current capacity per slot | [`searchTimeSlots`](./searchTimeSlots) | Browse-oriented. No customer-specific pricing, ladders, or quantity discounts.                              |
| Date-range schedule for a specific **admission** (admission-keyed, no pricing)           | [`getSchedule`](./getSchedule)         | Returns the schedule entries with their capacity-control mode and initial capacity. No `remainingCapacity`. |

All three share the same underlying domain.

## Key Concepts

* **Item Number**:
  Represents the product being sold at a high level. Each item number corresponds to a category
  or type of ticket, and the base price is associated with the item number. The base price is
  drawn from a general price list that applies across all similar items.

* **Admissions**:
  Admissions define the specific areas or events a ticket grants access to. Each admission has
  a unique admission code, along with descriptive information and various predefined limits, such
  as capacity or entry restrictions. These limits and policies can be set at different
  hierarchical levels, allowing flexibility in how capacity is controlled.

* **Schedules**:
  Admission schedules define when a location will be open or when an event will be occurring.
  Multiple schedules can be applied to the same admission. The setup defines how schedule
  entries are generated based on available rules. Only one entry per date is permitted, so
  automatic rescheduling is possible if the schedule definition changes.

* **Time-Based Validity**:
  In addition to defining what a ticket allows access to, the admission must also specify when
  the access is valid. Every admission needs to be linked to a specific time slot to ensure
  proper scheduling. In cases where the time is not explicitly provided, the system may assign a
  time slot automatically (defined by setup), which is particularly useful for scenarios like
  walk-up ticket sales at kiosks, where tickets should be valid immediately upon purchase.

* **Dynamic Pricing**:
  Each time slot can independently manage its pricing. While the base price is determined by the
  item number, time slots can either use a fixed price or apply dynamic pricing adjustments to
  the base price based on demand, capacity, or other factors.

* **Time Slot Visibility**:
  All available time slots are displayed to the consumer, even if they are no longer allocatable
  (e.g., fully booked or sold out). This is intentional, as it allows the system to provide
  visibility into popular events, offering a sense of urgency or exclusivity that can drive
  consumer interest.