Eine Kopie aktuell halten

Die meisten Anbindungen halten am Ende eine Kopie eines Teils des Bestands. Das schlecht zu tun ist der teuerste Fehler, den diese API zulässt, und er hat drei erkennbare Formen: alles per Zeitgeber erneut lesen, mit Offset blättern und einen fehlenden Datensatz als gelöscht behandeln.

Die Form, die funktioniert

1. Einmal auffüllen. Blättern Sie den Filter, der Sie interessiert, vom ersten bis zum letzten Cursor und speichern Sie die Datensätze dabei.
2. Die Hochwassermarke merken. Merken Sie sich das neueste gesehene updated_at, nicht die Laufzeit Ihres Jobs. Das ist verschieden, und in diesem Unterschied gehen Datensätze verloren.
3. Auf Änderungen abfragen. Fragen Sie mit updated_since einige Minuten vor dieser Marke.
4. Oder gar nicht abfragen. Webhooks machen diese Schleife ganz überflüssig und kosten kein Kontingent.

import { Skautik } from "@skautik/sdk";

const skautik = new Skautik({ apiKey: process.env.SKAUTIK_API_KEY! });

async function backfill(city: string) {
    let newest = "";

    for await (const property of skautik.properties.listAll({ city })) {
        await upsert(property);
        if (property.updatedAt > newest) {
            newest = property.updatedAt;
        }
    }

    return newest;
}

Der Iterator folgt dem Cursor für Sie und hält bei has_more an, was die einzige richtige Bedingung ist. Die Schleife von Hand zu schreiben ist der Ort, an dem man bei einer kurzen Seite anhält, und eine volle Seite kann trotzdem die letzte sein.

Das Fenster überlappen

Fragen Sie einige Minuten vor Ihrer Hochwassermarke, nicht die Marke selbst:

GET /v1/api/properties?city=Berlin&updated_since=2026-08-11T03:55:00Z

Datensätze werden nebenläufig geschrieben. Eine strikte Grenze verpasst alles, was einen Augenblick nach Ihrem Schnitt festgeschrieben, aber einen Augenblick davor gestempelt wurde, und dieser Datensatz fehlt dann, bis er sich zufällig erneut ändert. Denselben Datensatz zweimal zu verarbeiten kostet nichts, wenn Ihr Schreibvorgang ein Upsert ist; einen zu verpassen kostet Sie eine falsche Antwort über einen unbestimmten Zeitraum.

Abwesenheit ist keine Löschung

Ein Datensatz, der in einer gefilterten Liste nicht mehr auftaucht, ist nicht zwangsläufig weg. Er kann sich so geändert haben, dass er aus Ihrem Filter fällt: eine Preiserhöhung über Ihr max_price, ein Wechsel des Stadtteils, eine Rücknahme.

Eine Rücknahme ist ausdrücklich. Ein zurückgezogenes Objekt behält seine Kennung und bleibt über die id lesbar; sein Angebotsstatus lautet archived oder sold. Es verlässt die Standardliste, weil die Standardliste aktive Angebote zeigt, und nicht, weil es aufgehört hat zu existieren.

Also: Schließen Sie nie aus Abwesenheit auf Löschung. Abonnieren Sie entweder property.withdrawn oder fragen Sie den Status ausdrücklich ab, wenn Sie es wissen müssen:

GET /v1/api/properties?city=Berlin&status=archived

Wenn Ihre Kopie alles löscht, was aus einer gefilterten Seite gefallen ist, löscht eine einzige Preisänderung ein Objekt, das noch am Markt ist.

Was zu speichern ist

Speichern Sie mindestens die Kennung und updated_at. Die Kennung ist undurchsichtig und stabil; der Zeitstempel macht den nächsten Abgleich billig.

Speichern Sie außerdem external_id, wenn Sie zugleich die Quelle des Datensatzes sind. Es ist Ihre eigene Kennung, zurückgespiegelt, und sie erlaubt den Abgleich, ohne eine Zuordnungstabelle unserer ids zu Ihren zu führen.

Kosten

Die erste Zeile ist der Grund, warum es Kontingente gibt. Die dritte ist der Grund, warum es Webhooks gibt.

Wann ein Auffüllen das falsche Werkzeug ist

Dauerhafte Lesevorgänge des gesamten Bestands in großem Umfang sind besser über einen Export bedient als über schnelleres Durchlaufen. Ein Export ist eine Anfrage, erzeugt eine Datei und konkurriert nicht mit Ihrem eigenen Produktivverkehr um das Spitzenlimit. Fragen Sie uns, bevor Sie etwas bauen, das jede Nacht den ganzen Markt durchblättert.