In travel distribution, validity depends on the destination.

The same supplier dataset can look complete internally and still require different fields, mappings, or checks for Google Hotel Center, Wego, or trivago.

That is why I ended up separating two concerns in @metasearch/feed-validator:

1. canonical hotel normalization
2. platform-specific validation

Those two layers solve different problems, and mixing them creates false confidence.

Start with a canonical hotel model

Supplier feeds rarely agree on field names.

One source may send:

{
  "hotel_id": "TR-IST-001",
  "hotel_name": "Example Hotel",
  "country_code": "TR",
  "lat": 41.038,
  "lng": 28.986
}

Another may send:

{
  "property_id": "TR-IST-001",
  "name": "Example Hotel",
  "country": "TR",
  "latitude": 41.038,
  "longitude": 28.986
}

For internal processing, both records can be normalized into a shared model:

type CanonicalHotel = {
  id?: unknown
  name?: unknown
  description?: unknown
  address?: unknown
  city?: unknown
  province?: unknown
  postalCode?: unknown
  country?: unknown
  phone?: unknown
  latitude?: unknown
  longitude?: unknown
  link?: unknown
  image?: unknown
  brand?: unknown
  category?: unknown
  starRating?: unknown
  amenities?: unknown
}

That canonical layer is useful for mapping, comparison, observability, and downstream processing.

But it is not a platform contract.

Why one universal validator is misleading

It is tempting to create a generic score like:

“This hotel feed is 92% valid.”

But valid for what?

Google Hotel Center, Wego, and trivago do not expose identical hotel-data contracts.

A single generic score can hide the exact differences an integration engineer needs to see.

Instead, the validator keeps common parsing and normalization shared while applying destination-specific rule packs afterward.

You can run the same feed through several targets:

npx @metasearch/feed-validator compare hotels.csv \
  --targets google-hotel-center,wego,trivago

The useful question becomes:

What is missing for each destination?

rather than:

Is this feed globally valid?

Published-contract validation vs readiness checks

There is another distinction that matters: evidence quality.

The project currently treats Google Hotel Center, Wego, and trivago as published-contract validation targets because their implemented checks are based on maintainable first-party technical requirements.

Meta and Criteo are handled differently.

Those are explicitly labeled readiness checks, not certification.

That distinction is deliberate.

If the public technical contract is insufficient for a true validator, the tool should not invent undocumented mandatory fields just to make the interface look complete.

A developer tool should expose uncertainty instead of hiding it.

Same input, different target semantics

For example, the same synthetic hotel feed can be checked independently:

npx @metasearch/feed-validator validate examples/hotels.csv \
  --target google-hotel-center

npx @metasearch/feed-validator validate examples/hotels.csv \
  --target wego

npx @metasearch/feed-validator validate examples/hotels.csv \
  --target trivago

This makes target-specific gaps visible before partner onboarding or feed delivery.

The repository includes synthetic CSV and JSON examples so the workflow can be reproduced without production hotel data.

CI is where this becomes useful

Feed validation is most valuable before a partner receives a broken payload.

For example, a pull-request workflow can fail when a feed violates the configured threshold:

name: Validate hotel feed

on:
  pull_request:

jobs:
  validate-feed:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v5

      - uses: actions/setup-node@v5
        with:
          node-version: 22

      - run: >
          npx @metasearch/feed-validator
          validate path/to/hotels.csv
          --target google-hotel-center
          --fail-on error

The CLI uses deterministic exit codes:

• 0 — validation passed
• 1 — configured validation threshold failed
• 2 — input, fetch, parsing, or CLI error

For machine-readable pipelines:

npx @metasearch/feed-validator validate hotels.csv \
  --target google-hotel-center \
  --output json

One engine, several interfaces

The same validation model is exposed through several surfaces:

• CLI
• Node.js SDK
• browser validator
• remote MCP server

The browser validator is useful for quick inspection.

The remote MCP server exposes the same concepts to MCP-compatible clients.

That makes a workflow like this possible:

Detect the feed format, normalize the hotel records, compare Google Hotel Center, Wego and trivago requirements, validate each target, and explain the remediation steps.

The MCP server currently exposes 12 tools covering format detection, normalization, validation, platform comparison, and deterministic fix suggestions.

The architectural boundary matters

The important lesson is not specific to hotel feeds.

Canonicalization and validation are separate layers.

Canonicalization asks:

How can heterogeneous source records be represented consistently?

Validation asks:

Does this normalized data satisfy the contract of a specific destination?

When those layers are kept separate:

• supplier aliases stay out of platform rule logic,
• platform requirements do not pollute the canonical model,
• validation can evolve independently per destination,
• unsupported assumptions are easier to identify,
• CI failures become easier to explain.

That separation is especially useful in travel distribution, where one supplier feed may eventually be mapped to several metasearch, OTA, catalog, or channel destinations.

Open source

The implementation, synthetic sample feeds, and CI examples are available in the open-source metasearchcomtr/feed-validator repository.

There is also a hotel feed requirements comparison if you want to inspect the supported targets side by side.

I would be interested in hearing how other travel-tech teams separate normalization, mapping, and validation in their distribution pipelines.