DerbySoft Connectivity Integration Guide

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 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:

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.