DEV Community

HauchiKay
HauchiKay

Posted on

The Hospitality API Problem

#api #architecture #software #systemdesign

There is an interesting data problem hidden inside hotel and event-management systems.

A booking can tell a hotel that 120 people are expected at an event.

That does not tell the kitchen that it needs 120 portions of everything.

This distinction becomes important when a property manages conferences, weddings, banquets, breakfast service, room occupancy and restaurant demand at the same time.

The reservation system knows about guests.

The event-management system knows about attendees, function space, menus and resources.

The kitchen knows what was actually consumed.

Procurement knows what was purchased.

Waste systems know what was discarded.

These systems contain related information, but they are not necessarily operating from the same operational model.

Oracle's OPERA Cloud already exposes APIs for events, catering menus, event resources, reservations and production changes. Its event model can represent attendee numbers, function spaces and catering information, while its streaming infrastructure can expose reservation changes as business events.

The engineering opportunity is therefore not simply "add AI to the hotel."

It is:

Can these systems produce a reliable food-production signal from operational events?

Consider a conference booked for 200 people.

The original event might contain:

attendees: 200
breakfast: yes
lunch: yes
afternoon_tea: yes
dinner: no
Enter fullscreen mode Exit fullscreen mode

But three days before the event, the organiser changes the expected attendance to 164.

The system now has a choice.

It can update the event record and stop there.

Or the change can propagate through an event-driven workflow:

Event Management
       |
       | attendee.changed
       v
Demand Service
       |
       +----> Breakfast forecast
       +----> Lunch forecast
       +----> Beverage forecast
       +----> Procurement requirement
       +----> Kitchen production plan
       |
       v
Production System
       |
       v
Actual consumption
       |
       v
Waste / variance data
       |
       v
Forecast correction
Enter fullscreen mode Exit fullscreen mode

The second model is considerably more interesting.

The difficult part is not the API call

Changing attendees = 200 to attendees = 164 is easy.

The difficult question is what that number means operationally.

If 164 people attend, should the kitchen prepare 164 portions?

Probably not.

A buffet does not behave like a one-to-one transactional system.

The production quantity depends on variables such as:

  1. historical consumption
  2. menu composition
  3. meal period
  4. guest demographics
  5. event type
  6. portion size
  7. expected attendance
  8. no-show behaviour
  9. dietary requirements 10.service duration 11.replenishment policy 12.previous waste 13.popularity of individual dishes

A useful production service therefore needs something more sophisticated than:

required_quantity = attendees
Enter fullscreen mode Exit fullscreen mode

It might instead operate on:

required_quantity =
    expected_consumers
    × historical_consumption_rate
    × menu_factor
    × event_factor
    × confidence_adjustment
Enter fullscreen mode Exit fullscreen mode

The important point is that these factors should be "observable and explainable."

A kitchen manager should be able to see why the system recommended 38 kg rather than 45 kg.

This is where the data model becomes important

A hotel event record might contain:

{
  "event_id": "EV-10482",
  "attendees": 164,
  "event_type": "conference",
  "meal_period": "lunch",
  "menu_id": "MENU-22"
}
Enter fullscreen mode Exit fullscreen mode

That is not enough for production planning.

A useful downstream model might need to understand the relationship between:

Event
  ├── Attendance forecast
  ├── Menu
  │    ├── Dish
  │    ├── Recipe
  │    └── Ingredient
  ├── Service period
  ├── Consumption history
  ├── Production batch
  ├── Actual consumption
  └── Waste
Enter fullscreen mode Exit fullscreen mode

Now the system can begin answering a more useful question:

What should we produce, rather than simply how many guests have booked?

There is already movement in this direction

Winnow's newly announced Foresight product is particularly interesting because it moves food-waste technology upstream. Rather than only measuring waste after food has been produced, it uses occupancy and waste data to forecast kitchen demand before production. Winnow says its forecasts operate at individual food-item level.

That creates an interesting architectural possibility.

The booking system does not need to become the kitchen system.

The kitchen system does not need to become the booking system.

Instead, both can publish operational events.

For example:

reservation.updated
event.attendance_changed
event.menu_changed
event.cancelled
production.started
production.completed
consumption.recorded
waste.recorded
Enter fullscreen mode Exit fullscreen mode

A demand service can consume those events and maintain its own forecast.

This also solves an important integration problem: "systems should not need to constantly poll each other to discover changes."

Oracle's hospitality integration documentation already describes event subscriptions for reservation and profile changes, including ordered event consumption and follow-up retrieval of current state.

But there is a harder problem

What happens when the booking system says:

attendees = 164
Enter fullscreen mode Exit fullscreen mode

while the event manager has a spreadsheet showing:

attendees = 172
Enter fullscreen mode Exit fullscreen mode

and the kitchen has already produced:

180 portions
Enter fullscreen mode Exit fullscreen mode

This is no longer an AI problem.

It is a data consistency problem.

A production system needs:

  • source-of-truth rules
  • event ordering
  • idempotency
  • version numbers
  • timestamps
  • audit trails
  • correction events
  • human overrides
  • confidence levels
  • reconciliation

For example:

{
  "event_id": "EV-10482",
  "attendance": 164,
  "version": 7,
  "source": "event_management",
  "effective_at": "2026-10-02T14:30:00Z"
}
Enter fullscreen mode Exit fullscreen mode

A kitchen planning service should not blindly overwrite its state simply because another system sends a later HTTP request.

It should understand "which version of the event it is processing and when that change became operationally relevant."

The human override is equally important

A chef may know something the database does not.

Perhaps the conference is known to have unusually high consumption.

Perhaps the organiser has confirmed that 20 additional guests are arriving without updating the booking.

Perhaps one menu item is consistently popular.

The system should therefore recommend:

Recommended production: 42 kg
Confidence: 0.81
Historical consumption: +9%
Reason:
- 164 expected attendees
- conference lunch pattern
- menu contains high-demand chicken dish
- previous three comparable events exceeded baseline consumption
Enter fullscreen mode Exit fullscreen mode

Then the chef can approve:

Approved: 46 kg
Override reason: organiser confirmed additional guests
Enter fullscreen mode Exit fullscreen mode

That override becomes useful data for the next forecast.

This creates a feedback loop without pretending that the model knows everything.

The bigger hospitality opportunity

The same architecture could extend beyond hotels.

A university dining system could connect enrolment and meal-plan data with production.

A hospital could connect patient meal requirements with dietary production.

A cruise operator could connect passenger manifests with provisioning.

An airline could connect passenger manifests with meal loading.

A conference platform could connect registrations with catering requirements.

A contract caterer could connect client attendance changes with procurement.

The common problem is the same:

The system that knows who is coming is often not the system responsible for preparing what they will consume.

That is an integration problem worth solving.

Not because everything needs to become "AI-powered", but because hospitality has a large amount of operational data already being generated. The engineering challenge is making that data useful across the boundary between booking, planning, production and actual consumption.

The interesting question for developers is therefore not:

"How can we add AI to hotel software?"

It is:

"What event model and data architecture would allow a hospitality system to turn a changing booking into an explainable, auditable production plan?"

That is a problem I would be interested in seeing engineers tackle.

Top comments (0)