DEV Community

Cover image for Validate Google Hotel Center, Wego and trivago hotel feeds from CI
metasearch profile image Gökhan Kurt
Gökhan Kurt for metasearch

Posted on AI-assisted

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

#opensource #devops #travel #githubactions

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
Enter fullscreen mode Exit fullscreen mode

The same feed can be checked against Wego:

npx @metasearch/feed-validator validate hotels.csv \
  --target wego
Enter fullscreen mode Exit fullscreen mode

Or trivago:

npx @metasearch/feed-validator validate hotels.csv \
  --target trivago
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

You can also make the pipeline stricter:

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

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.

Top comments (0)