Using the Profitroom API for third-party integrations

The Profitroom API gives authorised third-party applications read and write access to reservation data, rate plans, guest profiles and channel configuration inside a Profitroom account. This article walks through the general shape of Profitroom API connectivity and how modules distributed through the Profitroomshop marketplace establish and maintain a connection over time.

Authenticating with the Profitroom API

The Profitroom API uses API-key authentication. Each Profitroom account can generate one or more API keys from the administration section of the Profitroom interface (typically Administration → Integrations → API Access). The key is a long alphanumeric string passed in the header of every request; it identifies the calling application and the property account it is authorised to reach.

Profitroom API keys can usually be scoped to specific permissions. Common scopes include: read reservations, write reservations, read rates, write rates, read guest profiles, write guest profiles, read channel configuration and read reporting data. Third-party applications should only request the minimum scopes their function requires — a least-privilege principle that limits exposure if a key is ever compromised.

Treat API keys as sensitive credentials. They grant complete access to the connected Profitroom property, up to the scope granted. They must be stored encrypted, transmitted only over HTTPS and rotated periodically. When you connect a module through Profitroomshop, your Profitroom API key is stored with AES-256 encryption at rest and is never exposed in clear text.

Reading reservation data from Profitroom

The Profitroom API exposes endpoints for querying reservations over a date range. A typical response includes: reservation identifier, guest name, arrival and departure dates, room type, rate plan, total amount, payment status, origin channel and guest contact details. This dataset is the foundation of most third-party integrations.

For modules such as the Cross-Sell Add-Ons and the REST API Custom Webhooks Extension the pattern is: (1) query Profitroom for reservations arriving in the next 14 days; (2) for each reservation, fetch the associated guest profile; (3) act on the guest data inside the module's function (send a pre-arrival portal link, for example); (4) write any results back into the Profitroom reservation record. Steps 1 and 2 are read operations; step 4 is a write operation that requires the "write reservations" or "write guest profiles" scope.

Rate management through the Profitroom API

The Profitroom API supports both read and write operations on rate plans. A typical write call specifies: the rate plan identifier (as defined in your Profitroom account), the arrival date or date range, the room type or types, and the new rate. Rate updates sent through the API flow into the Profitroom channel manager and are then distributed to the connected OTAs on the standard Profitroom refresh cycle.

Rate distribution over the API is the core function used by revenue-optimisation modules. The typical flow is: (1) read current rates and occupancy from Profitroom; (2) calculate a recommended or rule-driven rate; (3) push the new rate to Profitroom via the API; (4) Profitroom distributes the update to connected channels. Steps 1 and 3 require the read-rates and write-rates scopes respectively.

Webhooks and event-driven integrations

In addition to polling, Profitroom supports webhook delivery for certain reservation events. Once configured in your Profitroom account (typically Administration → Integrations → Webhooks), Profitroom will POST an HTTP request to a pre-registered URL whenever specific events occur — a new reservation is created, a reservation is modified, a check-out is finalised.

Webhook-based integrations are used by the Booking Recovery Automation and REST API Custom Webhooks Extension. When Profitroom fires a "check-out completed" webhook, the module immediately kicks off the appropriate post-stay sequence, without having to poll the Profitroom API every few minutes. This event-driven architecture reduces API call volume and improves response time for time-sensitive guest communication.

Rate limiting and call management

Profitroom applies rate limits to API calls to prevent system overload. Exceeding the limit results in HTTP 429 (Too Many Requests) responses. Well-designed third-party modules implement exponential back-off when they encounter rate-limit errors and batch requests wherever possible rather than making one call per room-night.

Modules distributed through Profitroomshop are engineered to respect Profitroom rate limits. Rate updates are batched wherever possible, polling intervals are set conservatively, and when several modules are active on the same Profitroom account the calls are coordinated to avoid piling on unnecessary volume.

Staying compatible with Profitroom API evolution

Profitroom publishes periodic updates to its API. Some add new endpoints or fields (non-breaking changes); others may deprecate or restructure existing endpoints (potentially breaking changes for dependent applications). Profitroomshop monitors the Profitroom API changelog and tests every module against each release. When a breaking change is detected, the affected modules are updated and a compatibility patch is typically shipped within 48 hours.