---
title: "DerbySoft Connectivity Integration Guide"
description: "Design DerbySoft-style hotel connectivity with push/pull boundaries, ARI ordering, mapping, booking reconciliation and provider-neutral observability."
slug: "derbysoft-connectivity-integration"
translationKey: "integration-derbysoft-connectivity"
locale: "en"
type: "guide"
category: "integration"
tags: ["derbysoft","connectivity","ari","push","pull","hotel-distribution"]
vertical: ["hotel"]
platform: "DerbySoft Connectivity"
domain: "derbysoft.com"
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
sources:
  - title: "DerbySoft Streamlined Connectivity"
    url: "https://www.derbysoft.com/streamlined-connectivity/"
  - title: "DerbySoft Property Connector"
    url: "https://www.derbysoft.com/property-connector/"
---
DerbySoft publicly describes hotel connectivity that can use push and pull API models across supplier and distributor relationships. Detailed partner schemas may be access-controlled, so the safest production design is to build a provider-neutral connectivity boundary rather than hard-code assumptions not supported by public documentation.

The [DerbySoft Connectivity profile](/en/metasearch/ecosystem/derbysoft-connectivity) covers the ecosystem role.

## Production scenario

A hotel changes price and availability while a distributor is pulling shopping data and a booking update is arriving. The integration must prevent old pushed state, new pulled state and booking lifecycle events from overwriting one another incorrectly.

## Push boundary

For push flows use:

```text
Source change
 -> canonical ARI event
 -> transactional outbox
 -> DerbySoft adapter
 -> delivery ledger
 -> retry / DLQ / reconciliation
```

Preserve source revision and entity/date ordering.

## Pull boundary

For pull/search flows, bound concurrency and cache behavior. Pull responses represent observed state at a point in time; they should not be silently written back as source-of-truth ARI.

## Mapping

Keep canonical property/room/rate identity separate from DerbySoft and downstream distributor identifiers. Mapping needs version, status and audit history.

## Booking lifecycle

Booking create/update/cancel state must be reconciled independently from ARI projection. A connectivity hub can move bookings between parties, but local systems still need idempotency and duplicate protection.

## Public documentation boundary

The public product pages describe flexible push/pull integration and distribution capabilities but do not expose every partner schema or contract. Exact request formats, certification rules and SLA values should be taken from partner documentation during implementation.

## Failure modes

Out-of-order ARI, mapping drift, duplicated booking updates, pull-cache staleness, retry amplification and assuming one integration contract applies to every downstream relationship are key risks.

## Observability

Track delivery lag, pull latency, mapping errors, booking reconciliation gaps, provider/distributor scope and retry depth.

## Production checklist

- provider-neutral canonical ARI model,
- separate push and pull pipelines,
- mapping versioning,
- delivery ledger,
- bounded retry,
- booking idempotency,
- reconciliation,
- per-partner metrics,
- explicit private-doc/version inventory.

Connectivity hubs reduce the number of direct connections, but they do not eliminate the need for source identity and state reconciliation.