What Is a Travel Feed? XML, JSON & Metasearch Data Flows

A feed is a structured machine-readable data flow used to synchronize information between systems.

Travel integrations may use XML, JSON, CSV or platform-specific formats. A feed is not merely a file; it also includes a data contract, update strategy and processing lifecycle.

When is a feed useful?

Feeds work well for bulk or repeated synchronization. Examples include property master data, static content, room metadata, rate-plan metadata and landing-page configuration. Highly dynamic live availability may require an API or push/query model in addition to feeds.

Hotel List feed

This carries property identity data such as partner property ID, name, address, country, coordinates, phone and website.

It is foundational to mapping quality.

Room and rate metadata

Useful fields include room name, occupancy, bed information, meal, cancellation policy and rate-plan labels. A price becomes meaningful to the traveler only when product semantics are clear.

Pricing and availability data

Some systems use feed or push patterns for rate and inventory changes. Important dimensions include effective dates, stay dates, inventory, restrictions, currency and tax/fee scope.

Landing-page configuration

Metasearch clicks need to reach the correct booking page.

Configuration may include URL templates, language, currency, device and campaign parameters.

Feed vs API

Feeds are typically batch or producer-driven. APIs are typically request/response and on-demand. Real integrations often combine them: property data through feeds, live availability through APIs and conversions through events/APIs.

Full vs incremental feed

A full feed sends the current complete state. It simplifies reconciliation but can be large. An incremental feed sends changes only. It is efficient but requires reliable change tracking and recovery.

Some systems combine periodic snapshots with incremental updates.

Idempotency

Processing the same feed twice should not corrupt state.

Stable IDs and deterministic upsert behavior are important.

Versioning

Schema changes can break integrations.

Use explicit versions, backward-compatible additions, deprecation windows and contract tests.

Validation

Validate required fields, enum values, dates, currency, duplicate IDs, coordinates, syntax and referential integrity before delivery.

Observability

Track generated, accepted and rejected records, processing time, last successful sync, schema errors and source-data freshness. A feed is not successful simply because a file was created; downstream processing must be visible.

Summary

A production feed requires:

stable identity + explicit schema + update strategy + validation + observability.

Treat a feed as a data contract, not a file transfer

CSV, XML or JSON is only the transport format. The real production contract is identity, schema version, required fields, update semantics and deletion behavior.

For a hotel catalog feed, answer:

• is provider property ID stable?
• is each record a full snapshot or delta?
• does a missing field mean unchanged or deleted?
• how is a closed property tombstoned?
• do image/amenity arrays replace or append?
• how does schema versioning evolve?

What should ingestion look like?

Receive
  -> checksum / size validation
  -> schema validation
  -> record parsing
  -> canonical mapping
  -> business validation
  -> quarantine invalid records
  -> stage
  -> diff
  -> publish
  -> reconciliation report

A controlled quarantine layer is usually better than either rejecting the entire feed for one bad row or silently dropping invalid records.

Common failure modes

• processing the same file twice,
• treating a partial upload as complete,
• unannounced schema changes,
• losing deletion semantics,
• provider ID reuse,
• encoding/locale problems,
• duplicate properties,
• processing an older feed after a newer one.

Store feed run ID, checksum and source timestamp to support idempotency.

Operational KPIs

• records received/accepted/rejected,
• duplicate rate,
• mapping success,
• quarantine count,
• feed age,
• ingest duration,
• schema error distribution,
• deleted/reactivated entities,
• last successful publication.

A feed is successful when canonical data is reliably published, not merely when a file arrives.