Revenue agent (API-first)

My rate-apply agent drives a browser, which is brittle when the UI shifts. The bigger prize is doing pace and pickup reads and pushing rate, restriction, and inventory changes through an API, cleanly, while complementing the RMS instead of rebuilding its pricing engine.

How it works

The key architecture finding is that Mews is itself the channel manager. Rates and restrictions pushed through the Mews Connector API auto-propagate to the OTAs. So most of this is an API problem, not scraping. A read-only pace module already reconstructs on-the-books, seven-day pickup, and pace-versus-last-year at matched lead time.

• Layered rollout: read-only pace, then gated rate override, then restrictions with auto-reversion, then event playbooks across properties.
• Every write passes an approval gate, a single-use signed token bound to the exact action, with a kill switch and audit journal.
• A few levers stay browser-only by necessity (cancellation policies, OTA member-rate blackouts) where the API is read-only.

Building. Read-only pace is built and validated against the demo environment, and a one-property pilot is staged. The long pole is external: minting per-property API tokens with write and distribution scopes.

This is the graduation from scraping to API, and from 'agent clicks for me' to 'agent proposes, I approve, agent executes safely.' Each layer that moves from browser to API is one more class of exception that stops needing my hands.