As you might have seen, two weeks ago we announced our new RM API, built to enable anyone to build robust tools on top of the Wheelhouse interface.

And, last week, we announce the Wheelhouse Hackathon (taking place July 20th).

And, this week, we've added new endpoints to the API on a daily basis... with more that are going live as this "goes to press"!

With this update, we're adding a huge amount of market data, for you to be able to analyze, communicate and adjust your pricing strategy, however you please. Enjoy!

Two new endpoints give your integration a daily view of what's happening around each listing:

Until now, the RM API gave you Wheelhouse's recommendations for your listings. Neighborhood Data gives you the market context those recommendations are built on — the daily pricing trends, occupancy rates, and booking pace for comparable properties in the same area.

This is especially useful for:

Each endpoint is scoped to a single listing and returns day-level data, so you can pull exactly the window you need.

This is the biggest of the three additions. Dynamic Sets are Wheelhouse's comparable property groupings — and they're now fully accessible via the RM API.

Nine new endpoints are available:

Dynamic Sets are how Wheelhouse models local market context for each listing. With these endpoints, you can:

The metrics and report endpoints in particular are useful for any integration that surfaces market benchmarking data — you're getting the same comp-set lens Wheelhouse's pricing engine uses.

Three endpoints give your integration access to Wheelhouse's market-level data:

All three endpoints support filtering by bedrooms (0–4+), property_type (house, apartment, cabin, etc.), and performance tier (low / average / high). The time-series endpoint supports date ranges up to 3 years back and 1 year forward.

This is the most data-dense addition in this release.

A few things you can build with it:

The distribution endpoint is particularly useful for owner reports: it lets you show where a listing sits in the market histogram for any given month — not just a market average, but the full spread.

A single new endpoint under the Calendar tag:

Wheelhouse generates price recommendations daily, but what actually lands on the OTA is the posted price — which can differ due to timing, overrides, custom rates, or channel-specific rules.

This endpoint closes that gap. You can now retrieve the last posted price for each stay date on any listing, enabling:

Reconciliation between Wheelhouse recommendations and what actually appeared on the channel

Audit logs or owner-facing reports that show "what we actually charged" vs. "what was recommended"

Debugging distribution issues — if a price didn't update as expected, this is the ground truth

Pair this with the existing Price Recommendations endpoint (GET ) to calculate the delta between recommended and posted prices — a useful signal for auditing override behavior or channel sync issues across your portfolio.

All these endpoint groups are available now under your existing RM API key.

No new authentication or setup required.

➡️ Full documentation: https://api.usewheelhouse.com/wheelhouse_rm_api

Questions or feedback? Our CS team is fully ready to help. Send us an email at hello@usewheelhouse.com, or simply open your normal chat window inside the App.

We're hosting our first-ever Hackathon 🏗️.

The Revenue Hackathon is aimed at teaching, sharing & building together.

This is open to anyone (customers, RM shops, developers in our industry, even our competitors), and will have for builders.

The goal is simple: leveraging (and data, MCP.)

Kickoff is Tuesday July 21 @ 8am PST — we'll start with an online gathering to say hello, give you an overview of some of your tools, and provide a place to meet other builders, in case you are looking for a team.

Throughout the Hackathon, we'll provide dedicated engineering & build support, to ensure the worst possible outcome is that you emerge with a powerful new skillset.

Well... anything!

Our RM API gives you access to live listing data, pricing infrastructure, and the full Wheelhouse platform.

Three days to build whatever you think is possible.

And... so much more.

Spots are limited... only in the name of over-delivering for those who participate.

Revenue metrics are the ones that matter most for day-to-day decisions, so we've made sure they say exactly what they mean.

"Nightly Revenue" is now . The definition is unchanged: it's the sum of rent prices for your Nights (Booked) — no fees, no taxes, no security deposits. Just rent. The rename makes it unambiguous as the clean baseline for better revenue management comparisons.

This is the one to pay attention to. What was previously called is now — and the calculation has changed. Security Deposits are no longer included.

Why does this matter? Security Deposits aren't revenue — they're liabilities until a stay is completed and reconciled. Including them in a top-line revenue figure made it harder to use the metric for actual revenue management. now means exactly what it says: rent + fees, for Nights (Booked). Cleaner input, cleaner analysis.

When you need the full gross number — for owner reporting, accounting, or gross revenue targets — gives you rent + fees + taxes for Nights (Booked). It's a new metric precisely because it serves a different purpose than the management-focused .

Across the full metrics update, you'll notice a consistent structural pattern: the base concept comes first, and qualifiers follow in parentheses.

For example:

Yes, some of these read a little formally. That's intentional.

The structure means that related metrics always sort and group together — everything under Occupancy is in one place, everything under Revenue is in one place, everything under RevPAR is in one place.

When you're scanning a long list of metrics to build a view or a report, that predictability is worth a lot more than a name that flows naturally in a sentence.

A few other naming updates worth knowing:

Every metric in this update is documented on the .

The long-form name (e.g., "Revenue (Adjusted Occupancy + Fees)") is listed there alongside the full definition.

Inside the product, you'll see the short name and acronym — hover over any metric to pull up the full definition without leaving your workflow.

This is especially useful for less intuitive metrics (we're looking at you, RevPAR (Adj. Occ, +Fees)) where the name alone doesn't tell the whole story.

To review these updates in full, our Metrics Lexicon page is fully up to date (and offers a few sneak previews)

TL;DR →

📖 Review the API Docs here

The Wheelhouse Revenue Management (RM) API gives you programmatic access to the full dynamic pricing stack.

That distinction matters. Most pricing APIs return a recommended rate.

The Wheelhouse RM API gives you read/write access to the controls behind the rate — base price strategy, seasonality curves, occupancy pacing, demand sensitivity, gap night fills, last-minute discounts, far-future premiums, check-in/out rules, and more.

If you're building an owner-facing dashboard, a view for your RM clients, or an internal analytics tool, this is the infrastructure that makes it possible to surface real revenue management controls — not just push numbers.

To start building, please fill out this form.

APIs used to be the playground for engineers. Not anymore.

With an LLM-based tool — Claude, ChatGPT, Cursor, take your pick — you can describe what you want to build, and start shipping customized workflow enhancements, without writing traditional code from scratch.

Want proof? The majority of the teams and individuals currently building on the RM API have zero or very limited engineering experience — and these builders were up and running within hours.

Owner dashboards. Automated pricing reports. Custom alert systems. The building blocks are here. And yes, you can build!

(PS - need help? Reach out to us to collab!)

One of the most distinctive capabilities of the RM API is the Preview / Simulation endpoint.

This endpoint accepts hypothetical preference changes and returns projected pricing — without saving anything.

This enables you to easily create a "what-if" UI that property managers and their owners have never had before: you can show exactly how a rate calendar would change before committing to it.

Change a base price, adjust a seasonality multiplier, tweak occupancy pacing — and see the full downstream impact, risk-free.

Pair the Simulation Endpoint with your Segments

Use Portfolio Segments to filter down to a specific group of listings, then run preview calls across each listing before applying a bulk preference update.

You'll have a full picture of the projected rate impact across your portfolio — before a single change goes live.

Every daily price recommendation from the Wheelhouse RM API includes optional per-factor attribution — a breakdown of exactly how each signal contributed to the recommended price.

The 10+ factors include: seasonality, local demand, time-to-booking, scarcity, occupancy pacing, any custom adjustments, and more.

For base price recommendations, you get an 8-factor breakdown plus an anchor credibility score from 0–100, indicating how confident the model is in the recommendation.

This means your integrations can explain pricing to property owners in plain language — not just show them a number.

Yes - you can now get the full calendar in one call.

This returns price, availability, booking state, and reservation ID for every stay date — up to 1.5 years out — in a single API call.

If you're building a calendar UI for owners or a booking tool for your team, this eliminates the need to cross-reference a separate availability source.

Everything you need to render a complete, accurate representation of your Wheelhouse calendar is available in one response.

The Wheelhouse RM API is designed for professional property management companies managing listings at scale:

Authentication uses a single RM API key — no separate opt-in, no additional per-listing configuration.

Read-only keys can be issued for analytics integrations and partner access that only need data, not write permissions.

Every write endpoint also includes concurrency protection (409 Conflict) when a request is already in progress for a given listing — production-safe for high-volume integrations.

The Wheelhouse RM API is now live, for anyone who wants early access.

To get started, please sign up here, and we’ll provision your account.

And, here is a demo of how you can get your API keys, once provisioned (hint - anyone can do it!).

Wheelhouse has long been known for our amazing, 24/7 Customer Support team.

And, we’re bringing that same team & approach to our API support.

We're here to help you build.

TL;DR →

---

Your pricing chart is one of the most-used surfaces in Wheelhouse — it's where you validate strategies, spot anomalies, and communicate pricing decisions to owners and teammates. Now you can make it look exactly the way you want.

The new lets you customize the visual appearance of every series on your chart — individually, with precision. Open it from your pricing chart by clicking the chart settings dropdown → → , and a new panel slides in on the right side of your screen.

From there, you're in control.

---

The Theme Editor shows your full list of chart series — Prices (Current Settings), Prices (Observed), Rent + Fee Preview, Base price, Min/Max price, Bookings, Set, Set median, and more. Expand any series to customize:

If you ever want to start fresh, simply click to brings every series back to its defaults in one click.

---

Once you've dialed in an appearance you like, save it as a named . Give it any name — "Owner Report View", "Alice's Setup", whatever makes sense for your workflow.

Switching between profiles is instant. This makes it easy to maintain different chart setups for different contexts: one optimized for your own analysis, another cleaned up for owner-facing conversations, a third for team reviews.

Wheelhouse ships with three ready-to-use profiles:

---

Your pricing chart surfaces a lot of data — easily 15+ series when you're looking at your full picture. The more series are active, the more important visual distinction becomes.

With the Theme Editor, you can make the series that matter most to your current analysis jump out at a glance. Heavier line weight on your Current Settings price. A distinct dash style on Last Year prices. Muted opacity on reference series you want visible but not dominant.

This kind of visual control is especially useful when:

---

📽️ Watch a demo — ![](

TL;DR →

--

"One-Sided Gaps" are now called Adjacencies. This name more accurately describes the function: targeting nights that sit directly next to a booking or a blocked period. You can still find these settings within the Min Stays menu.

--

Kegan, our Head of Onboarding, made an exceptionally thorough walkthrough video here:

--

Adjacency rules now feature Min and Max Lead Time logic. This allows you to trigger rules based on how close the stay date is to today.

Example: You can automatically drop a 3-night minimum to a 1-night minimum, but only if the gap is still unbooked within 7 days of arrival.

--

#New: 🛏️ Relative Min-Stay Adjustment

The system has moved from fixed stay requirements to Relative Adjustments. Instead of forcing a "2-night stay," you now adjust your base settings:

-1: Lowers your current min-stay by one night to fill a shoulder gap.

+2: Increases the requirement by two nights.

0: Maintains the status quo but allows the rule to function for lead-time or priority purposes.

Note: These adjustments respect your Absolute Min Stay floor; a rule will never push your requirements lower than your hard-coded minimum.

--

You can now copy Adjacency rules in bulk via Portfolio Settings > Minimum Stays. This is ideal for quickly rolling out a new shoulder-night strategy across an entire market.

You'll find Adjacencies in the Portfolio Settings > Minimum Stays bulk and copy flows, right alongside Gap Night rules.

Select a source listing with a well-configured Adjacency setup, choose your target listings, and copy.

This is especially useful if you've been manually replicating rules listing by listing. Whether you're rolling out a new shoulder-night strategy across a market or onboarding a new property type, portfolio-level copy makes it fast and consistent.

--

🔢 Advanced Conflict Resolution

A new prioritization toggle, "Priority by Smallest Subsequent Days," allows you to resolve rule conflicts. When enabled, the system will prioritize the rule targeting the smallest window of time, regardless of whether that window falls before or after a booking.

--

Adjacencies are available now for all customers.

To get started:

--

To maximize occupancy, use Gap Night rules (for gaps between two bookings) in tandem with Adjacency rules (for shoulder nights next to one booking). Together, they ensure your calendar remains flexible and protected regardless of how bookings land.

--

This is a seemingly small - but very powerful - feature. In this case, we truly believe this video is worth 1,000 words!

Your pricing chart and calendar are now stitched together.

When you click any point on your pricing chart, your calendar will automatically jump to that date — so the thing you noticed in the chart and the context behind it are always one click apart.

See an unexpected price spike three weeks out? Click it. Your calendar lands right there so you can check what's influencing that day — a nearby event, a gap, an override, etc.

Or, spot a low that doesn't look right, click it, and you're immediately in position to investigate and adjust.

It's a small change aimed to remove a common friction point — the back-and-forth of finding a date in the chart, then manually hunting for it in the calendar.

The Portfolio Calendar has always let you drag a contiguous set of date ranges & listings.

However, it did not enable you to pick scattered, non-adjacent nights and listings, and treat them as a single selection.

Until… now!

As of today, your portfolio calendar enables you to select any individual cells — across non-adjacent dates or listings — and apply a single bulk update across all of them.

This should make your pricing & settings updates much more targeted, precise, and fast.

While there are myriad use cases, here are a few worth highlighting:

It's not unusual to have 1–2 night gaps between reservations.

These gaps can be scattered all over your calendar — different dates, different listings, no perfect pattern.

Before, you'd have to hunt them down one-by-one, and make updates (e.g. lowering min prices, min stays, etc) one at a time.

Now, you can scan your calendar, click each orphan cell, and push updates across all selected cells at once.

To explore another use case, let’s imagine it's Thursday afternoon.

You have unsold nights this weekend scattered across 15 listings — different dates on different properties. You need to act before the weekend window closes.

Multi-select lets you build that exact set of cells — no matter how scattered — and cut rates or remove min stay restrictions across all of them in one shot.

Selecting multiple ranges is quite intuitive.

Simply hold the Control or Command key while making multiple selections.

As you add more cells, a counter shows how many cells, listings, and dates are in scope — so you can see the full picture before you apply any changes.

Accidentally add an extra date or listing?

Simply click that cell while still holding the Control or Command key, and you can easily modify your selection.

Or, close your side panel to one-click clear all active selections.

When your selection is ready, leverage your bulk updates tool much as before, to update any of the following:

And, you can even delete existing rates from all selected cells.

Every bulk update from this multi-range selection creates a changelog entry for each listing.

Each entry records who made the change, when, what was updated, and the specific dates affected for that listing.

Simply navigate to your Portfolio Calendar and start clicking cells to build your selection.

TL;DR →

----------

📡 5 New "In Context" Series

You now have 5 new data series available on any listing's pricing chart.

These series are designed to help you understand your neighborhood's prices and booking pace:

All booking series — Expected, Observed, and their range — are based on bookings in your listing's neighborhood.

We've pre-assembled these series into two new views so you can get to the signal instantly.

----------

From any listing's pricing chart, you can now open the view.

This view includes your standard series:

Plus all 5 new series:

Here's what that unlocks in practice.

Let's say it's early April and you're watching a holiday weekend in late May. The line is already running well above — your neighborhood is booking faster than the model predicted. That's a strong, data-backed signal that demand is spiking earlier than usual, giving you a concrete reason to be more aggressive on price now, before inventory tightens.

The inverse is equally useful: when Observed is lagging Expected, you have early visibility that pace is soft — and you can adjust strategy before it shows up in your own availability numbers.

This is the kind of signal that used to require piecing together comp data manually or waiting for a market report. Now it's right in your chart, and it .

To use it:

----------

The is purpose-built for one of the most important (and tricky) questions in modern STR pricing: what does my guest actually pay, and how does that compare to my neighbors?

Because fees vary by season, booking size, stay length, and channel, your "rent" price alone doesn't tell the whole story. This view brings it all together:

This should help you see exactly how your compare to

To use it:

The is most powerful once your is configured. Head to your listing's Settings → Rent + Fee Preview to confirm your fee load — or toggle on auto-detection so Wheelhouse keeps it current as your fee structure evolves.

📑 Want a reminder of our Model 9.0 Updates? Please read more here

Over the last 8 weeks, you provided a tremendous amount of feedback — often positive, but also constructive — that helped us improve two key aspects of the model. Thank you!

Here is what has been updated since launch:

Our event model is now better calibrated to real demand data. When we see early booking signals for a future event, the model more accurately translates that demand into prices that reflect what guests are actually willing to pay. In practice, this often means higher recommendations for future events with strong early demand — ensuring properties aren't leaving revenue on the table.

Wheelhouse's Pre-Demand Event Protection model ensures that prices reflect potential upcoming demand surges before bookings start rolling in. Based on your feedback and further analysis, we updated Model 9.0 so that PDEP recommendations are more tightly calibrated to what we expect to be the optimal price when future demand arrives.

With these changes locked in, we're now turning our research efforts toward Model 9.1.

The latest (and final) updates to Pricing Engine 9.0 will likely reduce how aggressively our pricing responds to local holidays and events.

Therefore, we recommend taking time to review your market’s major holiday periods to ensure your pricing—and any overrides—are delivering exactly the prices you want.

----------

As of today, Wheelhouse supports both Model 8.3 and Model 9.0. However, we will be phasing out Model 8.3 on , at which point all listings will be automatically moved to Model 9.0.

If you'd like to migrate before that date, Wheelhouse makes it easy to preview your 9.0 pricing, upgrade, and start taking advantage of a model that is driving significant revenue increases.

As a reminder, when we launched Model 9.0 in January, we planned to give users 90 days to evaluate and transition to the new model. Based on these recent updates, we've extended that window — while also making sure we can set the stage to bring Model 9.1 to market.