Data-API-Vergleichstool: Mehrere APIs mit SQL nebeneinander analysieren

Drei Anbieter, dieselben Daten — angeblich. Du rufst API A, B und C auf, speicherst je ein JSON-Blob und merkst: event_date (A), timestamp (B) und occurred_at (C) sind angeblich dasselbe Feld. Nach einem Tag Skripteschreiben weißt du immer noch nicht, welche API du nehmen sollst.

Das Problem ist nicht der API-Call. Das Problem ist die Normalisierung und der Vergleich.

TL;DR

• Schema-Mismatches zwischen Anbietern sind die eigentliche Arbeit, nicht die HTTP-Requests.
• Coverage und Vollständigkeit erkennst du erst, wenn du die Daten lädst und JOINst.
• Mit DuckDB-SQL kannst du mehrere API-Quellen nebeneinander in einer Query vergleichen.
• Harbinger Explorer lädt mehrere APIs als Tables und macht JOINs über Quellen hinweg möglich.

Warum API-Vergleiche schwerer sind, als sie aussehen

Schema-Mismatch

Jede API liefert ihre eigene Struktur. Selbst wenn zwei APIs dieselbe Information transportieren — News-Events, Finanzpreise, Wetterbeobachtungen — passen Feldnamen, Datumsformate, Granularität und Null-Handling nie zusammen. Wer hier falsch normalisiert, vergleicht Äpfel mit Birnen und vertraut dem Ergebnis.

Coverage ist unsichtbar bis du hinschaust

Dokumentation sagt dir, was prinzipiell verfügbar ist — nicht, wie vollständig die Daten für deinen Use Case wirklich sind. Anbieter A deckt Nordamerika sauber ab, hat aber Lücken in Südostasien. Anbieter B hat die letzten drei Jahre, vor 2021 wird es dünn. Das siehst du nur, wenn du die Daten lädst.

Rate Limits machen Tests teuer

Free Tier mit 100 Calls/Tag, danach kostet jede Evaluierung Geld. Du verbrennst API-Credits, um zu entscheiden, ob du den Anbieter überhaupt kaufst.

Das "Different Ground Truth"-Problem

API A sagt 147, API B sagt 152. Welcher Wert stimmt? Ohne Ground Truth kannst du das nicht definitiv beantworten — aber du kannst die Verteilung der Abweichungen verstehen. Dafür müssen beide Datasets in derselben Query-Engine landen.

Was Teams aktuell nutzen

Postman ist für Developer, die Endpoints testen — nicht für Analyst:innen, die Datasets vergleichen. Python-Scripts funktionieren, kosten aber einen Arbeitstag pro Vergleich, und bei Schemaänderung beginnst du von vorne.

Der bessere Weg: Mehrere APIs als Tables, SQL-JOINs darüber

Stell dir vor, du zeigst auf drei API-Endpoints, lädst alle Responses gleichzeitig und schreibst sofort SQL-JOINs über sie. Genau so funktioniert Harbinger Explorer.

Der AI Crawler lädt mehrere Datenquellen — APIs, CSVs, Web-Daten — und macht sie sofort mit DuckDB abfragbar. Jede Quelle wird eine Tabelle. Deine Vergleichslogik ist nur SQL.

Schritt-für-Schritt

1. Quellen anlegen. Jede API als Crawl-Target. Auth via API-Key oder Bearer-Token, Pagination wird gehandhabt.
2. AI Crawler laufen lassen. Jede API wird zur DuckDB-Tabelle (source_api_a, source_api_b, ...).
3. Column Mapping prüfen. Welche Spalten gibt es, welche entsprechen sich vermutlich? Das ist die manuelle Entscheidung, die kein Tool dir abnehmen kann.
4. Vergleichs-SQL schreiben:

SELECT
  a.event_id,
  a.event_date AS date_from_api_a,
  b.timestamp AS date_from_api_b,
  a.value AS value_api_a,
  b.value AS value_api_b,
  ABS(a.value - b.value) AS value_delta
FROM source_api_a a
JOIN source_api_b b ON a.event_id = b.event_id
WHERE ABS(a.value - b.value) > 5
ORDER BY value_delta DESC

5. Coverage-Gap analysieren:

SELECT a.event_id, a.region
FROM source_api_a a
LEFT JOIN source_api_b b ON a.event_id = b.event_id
WHERE b.event_id IS NULL

Advanced Patterns

Drei-Wege-Coverage-Matrix

SELECT
  COALESCE(a.region, b.region, c.region) AS region,
  COUNT(DISTINCT a.event_id) AS count_api_a,
  COUNT(DISTINCT b.event_id) AS count_api_b,
  COUNT(DISTINCT c.event_id) AS count_api_c
FROM source_api_a a
FULL OUTER JOIN source_api_b b ON a.region = b.region
FULL OUTER JOIN source_api_c c ON COALESCE(a.region, b.region) = c.region
GROUP BY region
ORDER BY count_api_a DESC

Freshness-Vergleich

SELECT 'API A' AS source, MAX(event_date) AS most_recent FROM source_api_a
UNION ALL
SELECT 'API B', MAX(timestamp) FROM source_api_b
UNION ALL
SELECT 'API C', MAX(occurred_at) FROM source_api_c
ORDER BY most_recent DESC

Verteilung vergleichen

SELECT
  'API A' AS source,
  AVG(value) AS mean,
  STDDEV(value) AS std_dev,
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY value) AS median
FROM source_api_a
UNION ALL
SELECT 'API B', AVG(value), STDDEV(value),
       PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY value)
FROM source_api_b

Wenn API A systematisch 5–10 % höhere Werte liefert als B, ist das ein systematisches Delta, das du verstehen musst, bevor du dich entscheidest.

Vergleich

FAQ

Welche API-Typen werden unterstützt? REST-APIs mit JSON-Response, CSV-Endpoints, strukturierte Web-Quellen. Auth via API-Key oder Bearer-Token, Pagination wird gehandhabt.

Wie viele Daten brauche ich für einen sinnvollen Vergleich? Für Coverage: genug, um deinen Scope abzudecken (z. B. Sample pro Region). Für Quality-Vergleich: ein paar tausend Records reichen meist für systematische Differenzen.

Was, wenn zwei APIs keine gemeinsame Key haben? Der schwierigste Fall. Column Mapping zeigt dir die verfügbaren Spalten, aber die Vergleichsdimension musst du wählen — manchmal sind aggregierte Statistiken die richtige Antwort statt Record-Level-Alignment.

Wird meine API-Daten gespeichert? Geladene Daten bleiben deiner Session erhalten, bei Pro auch sessionsübergreifend. Keine Nutzung fürs Training, keine Weitergabe. PII Detection markiert sensible Spalten.

Kann ich Vergleiche automatisieren? Pro-Nutzer:innen können Recrawling konfigurieren — wiederkehrendes Fetching auf Schedule. Wenn API-Qualität degradiert, fangen die Queries das ab.

Pricing: Starter 8 €/Monat (25 Chats/Tag, 10 Crawls/Monat) oder Pro 24 €/Monat (200 Chats/Tag, 100 Crawls/Monat, Recrawling). 7 Tage Trial ohne Kreditkarte.

Stand: 14. Mai 2026.