We didn't just build a website. We built the systems that run the rental.

Every day at 5:00 a.m. Pacific, an n8n workflow asks PriceLabs for a year of nightly rates and writes them into the site's price calendar. A second branch reads the minimum-price setting from PriceLabs and writes it as the "from" price on the listing card, so that headline tracks the floor rather than the cheapest night that happens to be coming up.

The job stops before writing if PriceLabs reports an error, if the pricing data was last refreshed more than two days ago, or if fewer than 30 priced nights come back. The minimum price has to be a real number inside a set range. Every network step is tried up to three times. The two-day check exists because a pricing service can answer successfully with data that has stopped updating, and every other signal would look healthy.

The job writes through code of our own on the site, installed so that a stray click in the admin does not switch it off. It fails closed: a request that does not explicitly ask for a live write is treated as a dry run and writes nothing.

The first draft of the integration had five defects, and four of them failed silently. One would have reported a complete success while writing nothing. The largest: the theme's built-in price writer is made to save one pricing period per request, so a year of nights could not go through it in one call. We rewrote the write to build the whole year in memory and save once. That write went from failing at 60 seconds to finishing in 1.6.

We did not trust the job's own report. Before the first live write we proved the job's date keys matched the theme's own, because a mismatch would have written prices to the wrong dates, then snapshotted the existing prices and wrote a one-command restore. After the write, we compared the site against PriceLabs night by night: 366 nights, zero mismatches, on September 1, 2026.

A second workflow is wired to the job as its error handler. When a run fails, it turns the error into a plain-language diagnosis and emails the operator. It names the likely cause: a wrong listing reference, pricing sync switched off at the source, rejected credentials, stale data, too few nights, a timeout on the site, or theme functions not loaded. It also states the consequence. The calendar keeps its last good prices, so a failed night means selling at stale rates, not selling at zero. It reports a run that fails. It cannot report a run that never starts.

The job failed on the two mornings after go-live, September 2 and 3. Two saved credentials in n8n had been filled in wrongly, so the pricing service never received its key. The alert that reached the operator on September 3 was for the second failed run; the record does not establish why no alert was seen for the first. With the credentials corrected, the next run completed and wrote nothing: the job's own dry-run setting was still on, a second fault. The site treats anything short of an explicit instruction to go live as a rehearsal. With the setting cleared, the run was checked against a fresh PriceLabs pull: 366 nights, zero mismatches, and the "from" price confirmed written. Two nights of stale rates, repaired and re-verified on the morning of September 3.

n8n keeps recent executions, not all of them. The 30 it held on November 10, 2026, one per day from October 12, all finished without error. That is n8n's own run status, not a check of the site; the night-by-night comparisons above are from September. Earlier runs are no longer retained, so we do not quote them. No failed run is retained in that window, so the alert has had nothing to report in it. The published workflow has not been edited since the September 3 repair, and the schedule held at 5:00 a.m. Pacific through the November clock change.