Best Practices & Polling - Pubrio Documentation

Echtzeit-Frequenz

Der Parameter frequency_minute steuert, wie oft Ihr Monitor scannt.

Einstellung	Verhalten	Anwendungsfall
`0` (Standard)	Echtzeit — Signale werden erkannt und zugestellt, sobald sie auftreten	Die meisten Monitore — schnellstmögliche Zustellung
`1 - 60`	Festes Intervall in Minuten	Wenn Sie einen vorhersehbaren Rhythmus wünschen
`60 - 1440`	Stündlich bis täglich	Digest-artige Zusammenfassungen, Signale mit niedrigerer Priorität

Mit frequency_minute: 0 erkennt und liefert Pubrio Signale, sobald sie auftreten — kein Polling, keine Verzögerung.

Retry-Konfiguration

Wenn eine Webhook-Zustellung fehlschlägt, helfen Wiederholungsversuche bei der automatischen Wiederherstellung.

Parameter	Bereich	Standard	Empfehlung
`max_retry_per_trigger`	0 - 3	1	Für kritische Monitore auf 2–3 setzen
`retry_delay_second`	1 - 5	1	3–5 Sekunden verwenden, damit vorübergehende Probleme sich lösen können

Wiederholungsversuche liefern denselben Payload erneut aus — sie führen die Signalerkennung nicht erneut aus und verursachen keine zusätzlichen Suchkredite.

Process Retry

Mit dem Endpunkt Process Retry können Sie eine bestimmte fehlgeschlagene Zustellung erneut versuchen. Wesentliche Vorteile:

Keine Kosten bei Fehlern — Ihnen werden bei einer fehlgeschlagenen Zustellung keine Credits berechnet. Credits werden nur bei erfolgreicher Zustellung verbraucht.
Fehlerbehebung — Wiederholen Sie einen fehlgeschlagenen Log-Eintrag, um Webhook-Probleme zu diagnostizieren, ohne neue Trigger zu erzeugen.
Option für ursprüngliches Ziel — Verwenden Sie is_use_original_destination, um mit dem Ziel-Snapshot aus dem ursprünglichen Log erneut zu versuchen — nützlich, wenn Sie Ihre Webhook-URL seit dem Fehler aktualisiert haben.

Fehlgeschlagene Zustellungen finden Sie über Statistic Logs und können sie einzeln wiederholen.

Fehlerbehandlung

Der Parameter max_failure_trigger (Bereich: 1–10, Standard: 5) steuert, wie viele aufeinanderfolgende Zustellungsfehler zulässig sind, bevor der Monitor automatisch pausiert wird. Empfohlenes Vorgehen:

Setzen Sie notification_email, um bei Fehlern benachrichtigt zu werden
Halten Sie max_failure_trigger für Produktionsmonitore bei 3–5
Verwenden Sie Statistic Logs, um Fehler zu diagnostizieren — prüfen Sie error_message und response_status_code
Reaktivieren Sie den Monitor nach der Fehlerbehebung über Update Monitor
Verwenden Sie Process Retry, um bestimmte fehlgeschlagene Zustellungen erneut zu versuchen

Polling mit Statistik-Endpunkten

Während Webhooks die Echtzeitzustellung übernehmen, bieten die Statistik-Endpunkte Monitoring-, Debugging- und Audit-Funktionen.

Überblicks-Polling

Verwenden Sie Monitor Statistics für eine Dashboard-Statusprüfung:

curl -X POST https://api.pubrio.com/monitors/statistics \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{ "profile_id": 1 }'

Liefert aggregierte Kennzahlen: Gesamtzahl der Monitore, Trigger heute vs. gestern, Erfolgsraten und Vergleichsraten.

Log-basiertes Polling

Verwenden Sie Statistic Logs, um den Trigger-Verlauf zu überprüfen:

curl -X POST https://api.pubrio.com/monitors/statistics/logs \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "profile_id": 1,
    "monitor_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "page": 1,
    "per_page": 10
  }'

Jeder Log-Eintrag enthält Status, Credit-Verbrauch, Anzahl der Signale/Unternehmen/Personen, Verarbeitungszeit und Fehlerdetails.

Kombinieren Sie die Webhook-Zustellung mit periodischem Log-Polling für maximale Zuverlässigkeit: Webhooks übernehmen die Echtzeitverarbeitung, während Log-Polling verpasste Zustellungen erfasst und einen Audit-Trail liefert.

Empfehlungen zur Skalierung

Fokussierte Monitore vs. breite Filter

Bevorzugen Sie fokussierte Monitore gegenüber übermäßig breiten. Ein Monitor, der „KI-Jobs bei US-Enterprise-Unternehmen” verfolgt, lässt sich leichter debuggen als „alle Jobs überall”. Fokussierte Monitore erlauben es Ihnen außerdem, unterschiedliche Signaltypen an unterschiedliche Webhook-Endpunkte zu routen.

Zuverlässigkeit des Webhook-Endpunkts

Ihr Webhook-Endpunkt sollte:

Innerhalb von 30 Sekunden antworten
Sofort 200 zurückgeben und Daten asynchron verarbeiten
Doppelte Payloads sauber handhaben (Idempotenz)
Alle eingehenden Payloads zu Debugging-Zwecken protokollieren

Verwaltung vieler Monitore

Verwenden Sie Get Monitor List mit Filterung:

Filtern nach detection_mode und destination_type
Sortieren nach last_modified oder last_trigger_at
Suchen nach Namen mit search_term

Verwenden Sie Monitor Statistics, um schnell unterdurchschnittlich performende Monitore zu erkennen.

​Echtzeit-Frequenz

​Retry-Konfiguration

​Process Retry

​Fehlerbehandlung

​Polling mit Statistik-Endpunkten

​Überblicks-Polling

​Log-basiertes Polling

​Empfehlungen zur Skalierung

Echtzeit-Frequenz

Retry-Konfiguration

Process Retry

Fehlerbehandlung

Polling mit Statistik-Endpunkten

Überblicks-Polling

Log-basiertes Polling

Empfehlungen zur Skalierung