Validate Google Hotel Center, Wego and trivago hotel feeds from CI

Gökhan Kurt — Fri, 09 Oct 2026 18:27:54 +0000

Validate Google Hotel Center, Wego and trivago hotel feeds from CI

Hotel distribution feeds look simple until you need to send the same property data to multiple platforms.

A typical hotel feed may contain:

property ID
hotel name
address
country
latitude and longitude
phone number
property type
star rating

The problem is that every distribution platform has its own contract.

A feed that looks complete internally may still fail onboarding or require additional mapping for Google Hotel Center, Wego, or trivago.

I wanted a simple way to catch these differences before a feed reaches a partner integration, so I built an open-source CLI:

@metasearch/feed-validator

It currently supports published-contract validation for:

Google Hotel Center
Wego Hotels
trivago

It also includes readiness checks for Meta and Criteo, plus a generic hotel master-data quality check.

The distinction is intentional: readiness checks are not presented as official certification.

Validate a hotel feed

You can run the validator directly with npx.

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

The same feed can be checked against Wego:

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

Or trivago:

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

The public repository also includes synthetic hotel feeds, so the examples can be reproduced without using production hotel or customer data.

Compare the same feed across platforms

In practice, the comparison workflow is often more useful than validating a single target.

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

This makes platform-specific gaps visible before implementation or onboarding.

The goal is not to force every platform into a fake universal schema.

Instead, the validator normalizes common hotel fields while keeping destination-specific validation rules separate.

That distinction matters.

Canonicalization answers:

How can heterogeneous supplier records be represented consistently?

Validation answers:

Is this data sufficient for this particular destination?

Those are different problems.

Use validation as a CI gate

Feed validation can also run as part of a pull-request workflow.

For example:

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 pipelines that need structured output:

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

You can also make the pipeline stricter:

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

Supported input formats

The validator currently supports:

CSV
TSV
JSON
NDJSON
XML

Input can come from a local file, a public HTTP/HTTPS URL, or stdin.

That makes the same validation engine usable locally, in CI, or through the Node.js SDK.

Why platform-specific rules matter

One of the main design decisions was not pretending that every hotel distribution platform has the same schema.

Google Hotel Center, Wego, and trivago have different field expectations and integration models.

A universal "hotel feed score" can hide exactly the differences an integration engineer needs to understand.

The validator therefore uses target-specific rule packs.

Published-contract validation is only used where maintainable first-party technical requirements are available.

When a public contract is not sufficient for a true validator, the feature is explicitly labeled as a readiness check instead.

No undocumented mandatory fields are invented.

The same workflow is also available over MCP

The validation engine is also exposed through a public remote MCP server.

That allows MCP-compatible clients to perform workflows such as:

Detect this feed format, normalize the hotel records, compare Google Hotel Center, Wego and trivago requirements, and explain what should be fixed.

The MCP server currently exposes 12 tools covering feed detection, normalization, validation, platform comparison, and remediation suggestions.

So the same underlying workflow can be used from:

the CLI
Node.js
CI/CD
a browser tool
MCP-compatible AI clients

Open source

The Feed Validator and MCP companion project are both open source.

The repository contains synthetic sample feeds and copy-paste CI examples, so you can try the workflow without preparing a real supplier feed.

I'm especially interested in feedback from developers working with hotel distribution, channel management, OTA connectivity, metasearch, or travel-tech data pipelines.

If you work in this area, I'd be curious to hear which feed validation problems cause the most friction in your integrations.

DEV Community: Gökhan Kurt

Validate Google Hotel Center, Wego and trivago hotel feeds from CI

Validate Google Hotel Center, Wego and trivago hotel feeds from CI

Validate a hotel feed

Compare the same feed across platforms

Use validation as a CI gate

Supported input formats

Why platform-specific rules matter

The same workflow is also available over MCP

Open source