MetaSearch Benchmark Methodology: API Latency and Reliability

This page defines how metasearch.com.tr measures API latency and reliability. The goal is not to create a provider ranking; it is to measure comparable travel API scenarios under conditions that are explicit, reproducible and easy to audit.

Measurement unit

The base observation is one outbound HTTP request. Each observation records at least target/provider, scenario, start time, duration, HTTP status, timeout/error class, response size, cache mode, test region, run ID and methodology version.

OpenTelemetry defines HTTP client request duration as a standard telemetry metric; this benchmark schema follows the same general measurement model.

Latency metrics

A single average is not sufficient. For every comparable target/scenario publish at least p50, p95, p99, minimum/maximum, success count, timeout count and error count.

Percentiles must be reproducible from the raw request-level dataset.

Reliability

Reliability is not only the HTTP 5xx rate. Keep separate classes for success, HTTP 4xx, HTTP 5xx, timeout, DNS/network/TLS errors, malformed/unexpected responses and rate-limit responses.

Provider-specific business errors may be reported separately but must not be assumed equivalent across APIs.

Warm and cold cache

Warm-cache and cold-cache observations must not be mixed into one latency distribution.

If cache behavior cannot be verified externally, label it as unknown. Connection reuse, DNS and TLS effects should also be disclosed where relevant.

Geography and environment

Every run records test region, country, runtime, Node.js version, proxy/VPN use, run start/end time and network details when they are known.

Results measured from one region must not be presented as global performance.

Sample size and test window

For each public release disclose sample size per target, test window, request spacing, time-of-day distribution where relevant and retry behavior.

The default methodology avoids burst traffic and must not intentionally pressure provider rate limits.

Request pacing

The reference runner is intentionally conservative:

• concurrency: 1,
• minimum interval: 1 second,
• maximum 100 requests per target.

Higher-rate testing requires explicit permission and should be published as a separate methodology.

Provider and ToS boundary

Only endpoints the researcher is authorized to access may be benchmarked.

Public documentation does not automatically grant permission to publish performance results. Credentials must never be committed. If an active contract restricts publication, results remain private.

Comparable scenarios

Do not compare endpoints that perform materially different work in a single “fastest provider” table.

Useful scenario families include hotel content lookup, hotel availability/search, price confirmation/recheck, flight indicative search and flight live search.

Response completeness

Low latency is not sufficient. Where possible also record result count, payload size, partial-result flags and response validation state.

If speed trades off against completeness, disclose it.

Reproducibility

Every public benchmark release should include methodology version, runner version/commit, sanitized config, raw CSV/JSON, aggregate summary, environment metadata and known limitations.

Never include secrets, PII or contract-confidential data in public datasets.

Conflict of interest

Any commercial relationship between metasearch.com.tr, related products and measured providers must be disclosed on the benchmark page.

A sponsor may not alter the methodology or reported result.

Methodology version

Initial version: v1.0 — 2026-09-26

Material methodology changes require a new version. They must not be silently retrofitted onto older datasets.

Publication threshold

A study is called a benchmark only when raw observations are retained, methodology version is known, environment and sample size are disclosed, scenarios are comparable, results are reproducible and limitations are published.

Otherwise it must be labeled exploratory measurement.