> For the complete documentation index, see [llms.txt](https://docs.prioticket.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prioticket.com/key-concepts/availability-and-capacity/capacity.md).

# Capacity

### What is Capacity?

Capacity limits how many participants can book a product within a time slot, preventing overbooking and managing resource allocation.

***

### Capacity Types

1. **Unlimited Capacity**
   * No maximum limit; bookings are always accepted.
   * Common for virtual experiences or events without physical constraints.
2. **Fixed (Limited) Capacity**
   * A hard limit on how many participants can book a slot.
   * Once full, no additional bookings can be made.
3. **Product-Dependent Capacity**
   * Specific to an individual product.
   * Even if multiple products are similar, each has its own separate capacity pool.
4. **Shared Capacity**
   * Several products draw from the **same capacity pool**.
   * Example: A tour and a museum ticket share the same 30-seat bus.
5. **Combined Capacity**
   * A hybrid setup where multiple capacities (shared, fixed, or new) are merged for a product.
   * Used for custom reseller rules or group packages.
6. **Allocated Capacity**
   * Reserved capacity segments for specific distributors or channels.
   * Ensures availability for high-priority partners even when general capacity is exhausted.

***

### Configuration Strategies

**Per Sub-Product**

* Each sub-product in a combi setup must have its own capacity setting.
* Bookings fail if one sub-product lacks capacity, even if others have availability.

**Combi-Level Capacity**

* Can reflect the lowest capacity among sub-products or be configured independently.
* Example: A "Tour + Meal" product can have its own 20-person limit, even if the meal supports 50.

**Capacity IDs**

* Unique identifiers used to track capacity pools.
* Helpful for linking shared and allocated capacities across APIs and systems.

**Booking Validation**

* Capacity checks are enforced during the booking request.
* Must ensure the requested number of people or tickets doesn’t exceed the limit.

***

### Capacity Visuals

* Often displayed as **color-coded slots**:
  * 🟢 Green: High availability
  * 🟡 Yellow: Limited slots remaining
  * 🔴 Red: Fully booked or blocked
* Be aware of UI discrepancies across systems or resellers.

***

### Capacity Best Practices

* Use **shared capacity** only where operationally justified (e.g., same room, guide, or equipment).
* Regularly audit capacity usage to spot bottlenecks or over-allocations.
* Configure **fallback logic** (e.g., alternate time slots) to improve booking success rates.
* Keep capacity ID naming clear and consistent.
* Simulate edge cases (e.g., near-full or last-minute bookings) in staging environments.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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://docs.prioticket.com/key-concepts/availability-and-capacity/capacity.md?ask=<question>
```

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.