Skip to content
Browse documentation

Administration & integrations

Plan a website or partner integration

Define the data, access and verification your connection needs before a website, portal or partner system goes live.

3 min read·Reviewed

On this page

An integration connects two operating systems with their own responsibilities. REX-OPS includes API and feed workflows for inventory and partner use, alongside lead intake. Start with the outcome and the data boundary before choosing a technical method.

Define the exchange

Write down what the receiving system needs to read or send. Common examples include publishing selected inventory to a website, distributing listings to a portal or routing an enquiry into the sales workflow.

  • Identify the source of truth for each field.
  • Define which projects, units or records are in scope.
  • Agree how availability and price changes are handled.
  • Define who monitors failures and who can change the connection.

An outbound listing connection and an inbound enquiry connection are separate workflows. Verify each one independently, even if they serve the same website.

Obtain the current technical contract

Ask for the API specification or feed format approved for the connection and environment. Confirm the base URL, authentication method, permitted operations, required fields and rate or usage limits with the implementation team.

This guide explains integration planning. It deliberately does not publish request examples or endpoint details that may differ from the contract issued for your workspace.

Design for ordinary failures

Agree what happens when a request times out, a listing is rejected or a receiving system is unavailable. A timeout does not always mean a write failed: the recipient may have accepted the request before the response was lost.

Use the duplicate-prevention, delivery status and retry mechanisms defined in the actual integration contract. Avoid repeatedly sending the same lead or transaction without a way to establish whether it was already accepted.

Verify the whole path

  1. Use the approved test environment and representative non-sensitive data.
  2. Check the source record and intended publication scope.
  3. Inspect what the receiving system actually displays or stores.
  4. Change a relevant field and verify how the update arrives.
  5. Exercise a failure and confirm that the responsible team can identify it.

For lead intake, acceptance at an HTTP endpoint is only one checkpoint. Confirm the enquiry reaches the intended workspace with its contact details, source and owner or routing process intact.

Plan operation and change

Record the owner, configuration location, credential rotation process and monitoring responsibility. Re-check the connection when either side changes its contract, publication rules or access model. Portal refresh schedules and capabilities vary; agree the expected behaviour for each channel.

See API & Integrations, inventory and contact the team for a technical evaluation.