TECHNOLOGY PARTNERSHIPS

Connect reservation data to the financial work around it.

Operent handles the financial side of short-term rentals: each property's result, the owner payout and the month-end close. With the customer's permission, we want to receive the properties and bookings already in your platform, so nobody types them twice.

No partner integration is live yet. We're choosing the first ones.

Production platform · Controlled pre-launch · Real users

  • Booking platforms
  • PMS
  • Channel managers
  • Financial platforms
Operent Financial operations
Sources are designed to connect directly to Operent

WHAT WE PROPOSE

A read-only pilot.

Start small, with low risk on both sides.

What Operent would read
Properties and reservations.
Whose data
Only shared customers who authorize the connection.
What we don't do
No writes to your system. No pricing, calendar, guest messaging or payments.
On your side
Read access through an API or export, for those customers.
What you get
Shared customers with their month-end close handled, without you building that financial layer.
Size and duration
A few shared customers over a short period, agreed with you before we start.
How we measure it
Reservations arriving with no manual entry and no duplicates, and those customers closing their month in Operent.

Other paths, if they fit you better: a booking platform connection, a channel manager connection, financial interoperability, or starting with a technical conversation.

A NARROW, PRACTICAL CONNECTION

How a connection would work, in four steps.

It works with a booking platform, a PMS, a channel manager or a mix, each connected on its own.

01

The customer would authorize the connection

The customer would connect their account through an approved authorization process.

Operent would receive only the access and data permitted for that customer and integration.

02

Properties would be matched or initialized

The customer would select which properties should be connected.

Where the partner allows it, the property's basic data (listed in the table below) is used to identify, match or create the matching property in Operent.

03

Reservations would stay synchronized

When supported by an approved integration, a new source reservation would create the corresponding reservation in Operent:

  • a new reservation would create a linked record
  • a reservation change would update the linked record
  • a cancellation would update the reservation status
  • repeated synchronization would not create duplicate reservations
04

Operent handles its financial domain

Once the reservation exists in Operent, it can support the customer's financial workflows. Depending on the customer's configuration, this may include:

  • revenue organization
  • channel fees
  • management fees
  • property-level financial activity
  • owner balances
  • expenses
  • reconciliation
  • closing
  • reporting
See a connection example

Without connection

  1. Source reservation
  2. Manual property setup
  3. Manual reservation entry
  4. Manual updates and cancellations

With connection

  1. Source reservation
  2. Authorized synchronization
  3. Operent
Illustrative example, not a live connection.

Operent property

Internal name
Port Marlin 101
Owner relationship
Configured in Operent
Management fee
Configured in Operent
Allocation center
Configured in Operent
Business time zone
Confirmed by the customer

Linked external record

Provider
Booking platform
External listing name
Ocean View Apartment Near the Beach
External listing ID
987654321
Sync status
Example

The external commercial name can remain different from the internal name used by the customer. The relationship is preserved by the external identifier, not by matching names manually.

Integration availability depends on each approved partnership, technical implementation and authorized data scope.

MINIMUM DATA. DEFINED PURPOSE.

Request only what the connected workflow requires.

The exact data scope must be agreed with each partner.

For a property and reservation synchronization use case, the initial request should be read-only and limited to the fields required to identify, create and keep records aligned.

See the fields and purposes table
Request only what the connected workflow requires.
Data Potential fields Purpose
Property information
  • external property or listing ID
  • property name
  • address or location
  • time zone
  • primary image or approved image reference
  • source status
  • source update timestamp
  • identify the source property
  • match an existing Operent property
  • reduce duplicate setup
  • help the customer recognize the property
  • associate reservations with the correct property
Reservation information
  • external reservation ID
  • external property or listing ID
  • reservation status
  • check-in date
  • check-out date
  • number of guests
  • limited guest identification where required and authorized
  • currency
  • relevant reservation amounts where required and permitted
  • source creation timestamp
  • source update timestamp
  • cancellation status
  • create the corresponding reservation
  • prevent duplicate records
  • associate it with the correct property
  • reflect changes and cancellations
  • support the customer's configured financial workflows
Synchronization metadata
  • provider
  • connection ID
  • external record ID
  • source version or update timestamp
  • last synchronization time
  • synchronization result
  • error status
  • revocation status
  • make synchronization traceable
  • process updates safely
  • prevent duplicate records
  • detect failed or outdated synchronizations

Data not required for the initial use case

Operent does not need generic access to platform data.

The initial connection does not require:

  • guest messages
  • private message history
  • reviews
  • search or browsing behavior
  • market-wide pricing data
  • competitor pricing
  • identity documents
  • payment-card information
  • full guest profiles
  • listing publication controls
  • pricing write access
  • availability write access
  • reservation write access
  • guest communication access

Least privilege by default.

  • User-authorized The connection would be established on behalf of a customer authorized to access the source account.
  • Read-only first The initial property and reservation use case does not require Operent to modify the source platform.
  • Data minimization Only information required for the connected functionality should be processed.
  • Tenant isolation Imported information must remain associated with the correct Operent company and authorized users.
  • Traceability Each synchronized record would retain its provider, external identifiers and synchronization history.
  • Idempotency Repeated delivery or retrieval of the same source record must not create duplicate properties, reservations or financial records.
  • Controlled updates Changes would be applied according to explicit field ownership and synchronization rules.
  • Revocable access Connections must support authorization revocation and controlled handling of retained data.

Operent does not treat web scraping as a production partnership integration model.

WHERE EACH SYSTEM ENDS

Each platform remains authoritative in its own domain.

A financial operations platform for short-term rental businesses.

Operent connects properties, reservations, owners and the management company to a structured financial base.

Not a PMS

Where a customer already runs a PMS, that system stays the record of the stay and of distribution. Operent is designed to connect to it, not to replace it.

Not a channel manager

Operent does not distribute inventory between booking channels.

Not a marketplace

Operent does not sell accommodation or compete for bookings.

Not a pricing engine

Operent does not use partner data to compare or determine market pricing.

Not a listing manager

Operent does not need to publish or manage listing content for the initial synchronization use case.

Not a data reseller

Operent does not request partner data to create a generic external database or redistribute it to unrelated third parties.

Frequently asked questions

The questions partner and integration teams usually raise first, about scope, permissions and product boundaries.

No. Operent is designed to support different technology stacks. Where an approved integration is available, a booking platform, PMS, channel manager or other source could each connect directly to Operent. A PMS or channel manager is an option, not a requirement.

Not for the initial property and reservation synchronization model. The proposed initial scope is read-only. Operent would receive the authorized information required to initialize or match properties and keep reservations aligned. Any future write functionality would require a separate use case, explicit partner approval and its own permission scope.

No. Operent only needs the fields required to identify or initialize the corresponding property and associate reservations with it. It does not need to reproduce or republish the complete listing.

Yes, the model is designed for that. The same real-world property can have different external identities in a booking platform, PMS, channel manager or other system. Operent would maintain the internal property while preserving each authorized external relationship independently.

PARTNER WITH OPERENT

Let's define one useful connection.

Tell us which customer workflow your platform and Operent could improve together.

We will start with the smallest responsible scope that can deliver measurable value to shared customers.

Partnership contact [email protected]

Talk to Operent

Tell us what it's about and we'll reach out on WhatsApp. 15 minutes, no commitment.

WhatsApp