Skip to main content
POST
Monitor erstellen

Autorisierungen

pubrio-api-key
string
header
erforderlich

Ein eindeutiges API-Token, das die von Ihnen über die API durchgeführten Aktionen sowie die zugehörigen Berechtigungen und Vorgänge repräsentiert. Sie können es über den Bereich Settings erstellen.

Body

application/json
query
string
erforderlich

Eine Beschreibung des Monitors in natürlicher Sprache (beliebige Sprache), z. B. "monitor companies expanding into Japan, get C-level people with their work email, and email alerts to [email protected] in real time". Sie wird innerhalb derselben Anfrage in die untenstehenden Felder interpretiert (detection_mode, signal_types, signal_filters, people_enrichment_configs, destination_type/destination_config, frequency_minute). Jedes Feld, das Sie zusätzlich explizit angeben, überschreibt den interpretierten Wert. Wenn der Text keine Monitor-Anfrage ist, gibt der Aufruf 400 zurück. Auf 2000 Zeichen begrenzt.

Maximum string length: 2000
name
string

Name des Monitors.

description
string

Beschreibung des Monitors.

status
enum<string>
Standard:active

Lebenszyklusstatus, mit dem der Monitor erstellt werden soll. Standardmäßig active. Verwenden Sie draft, um einen halb fertigen Monitor zu speichern: Nur name ist erforderlich, die Validierung wird bis zur Aktivierung verschoben, und ein Entwurf wird nie ausgeführt.

Verfügbare Optionen:
draft,
active,
paused,
inactive
detection_mode
enum<string>

Wie Signale erkannt werden. signal_first durchsucht den Markt breit; company_first verfolgt eine benannte Kontenliste und erfordert mindestens ein Unternehmen, eine Domain oder eine LinkedIn-URL. Nach der Erstellung unveränderlich — das Ändern bei einem bestehenden Monitor gibt 40021 zurück. Erstellen Sie stattdessen einen neuen Monitor.

Verfügbare Optionen:
company_first,
signal_first
signal_types
enum<string>[]

Zu überwachende Signaltypen.

Verfügbare Optionen:
jobs,
news,
advertisements,
expansions,
cloud_footprints
signal_filters
object[]

Ein Eintrag pro Signal-Stream, den der Monitor überwacht.

Beispiel:
company_filters
object

Globale Unternehmensfilter, die als zweite Ebene über alle Signaltypen hinweg angewendet werden. Akzeptiert dieselben Parameter wie der Unternehmenssuche-Endpunkt — Standorte, Mitarbeiterzahl, Technologien, Branchen und mehr.

Beispiel:
companies
string<uuid>[]

Liste von zu überwachenden domain_search_id-UUIDs von Unternehmen. Wird hauptsächlich im company_first-Modus verwendet, um Zielunternehmen anzugeben. Sie können alternativ auch domains oder linkedin_urls verwenden — nur eines der drei ist erforderlich.

domains
string[]

Liste der zu überwachenden Unternehmensdomains (z. B. ["openai.com", "google.com"]). Alternative zu companies — Pubrio löst diese zu den entsprechenden Unternehmen auf. Nur eines von companies, domains oder linkedin_urls ist erforderlich.

linkedin_urls
string<uri>[]

Liste der zu überwachenden LinkedIn-Unternehmens-URLs (z. B. ["https://linkedin.com/company/pubrio"]). Alternative zu companies — Pubrio löst diese zu den entsprechenden Unternehmen auf. Nur eines von companies, domains oder linkedin_urls ist erforderlich.

is_company_enrichment
boolean

Ob Unternehmensdaten in den Ergebnissen angereichert werden sollen.

is_people_enrichment
boolean

Ob Personendaten in den Ergebnissen angereichert werden sollen.

people_enrichment_configs
object[]

Array von Personenanreicherungs-Ebenen. Jede Ebene führt eine unabhängige Personensuche aus. Enthält max_people_to_return (1-25), people_contact_types (Array — bezieht sich auf Redeem-Kontakttypen: email-work, email-personal, phone) und filters (dieselben Parameter wie der Personensuche-Endpunkt).

Beispiel:
destination_type
enum<string>

Typ des Zustellziels.

Verfügbare Optionen:
webhook,
email,
sequences
destination_config
object

Konfiguration des Ziels. Für Webhook: erfordert webhook_url (String), optional headers (Objekt) und body (Objekt). Für E-Mail: akzeptiert email (String) oder emails (Array von Strings). Für Sequenzen: erfordert sequence_identifier (String) plus mindestens eines von is_people_search_enrolled / is_company_contact_enrolled auf true gesetzt.

Beispiel:
frequency_minute
integer
Standard:0

Auslösefrequenz in Minuten. Min: 0, Max: 10080, Standard: 0.

Erforderlicher Bereich: 0 <= x <= 10080
max_failure_trigger
integer
Standard:5

Maximale Anzahl aufeinanderfolgender Fehlschläge, bevor der Monitor pausiert wird. Min: 1, Max: 10, Standard: 5.

Erforderlicher Bereich: 1 <= x <= 10
max_daily_trigger
integer
Standard:500

Maximale Anzahl von Auslösungen pro Tag. Min: 0, Max: 86400, Standard: 500.

Erforderlicher Bereich: 0 <= x <= 86400
max_records_per_trigger
integer
Standard:25

Steuert die maximale Anzahl der pro Auslösung zugestellten Datensätze. Niedrigere Werte verringern die Payload-Größe pro Zustellung, was für große Ergebnismengen oder ratenbegrenzte Integrationen empfohlen wird. Min: 1, Max: 100, Standard: 25. Weitere Hinweise finden Sie unter Webhooks einrichten.

Erforderlicher Bereich: 1 <= x <= 100
excluded_companies
string[]

Unternehmen, die dieser Monitor nie liefert oder abrechnet, als domain_search_id-UUIDs. Gilt in beiden Erkennungsmodi zur Laufzeit, vor Anreicherung und Abrechnung; ein Unternehmen, das sowohl in companies als auch in dieser Liste steht, ist ausgeschlossen, solange es auf der Liste steht. Maximale Listengröße: 100.000 (aufgelöste IDs aus excluded_companies, excluded_domains und excluded_linkedin_urls).

Beispiel:
excluded_domains
string[]

Auszuschließende Unternehmensdomains (z. B. ["existing-client.com"]). Werden zu Unternehmen aufgelöst und in excluded_companies übernommen.

Beispiel:
excluded_linkedin_urls
string[]

Auszuschließende LinkedIn-Unternehmens-URLs. Werden zu Unternehmen aufgelöst und in excluded_companies übernommen.

Beispiel:
record_unit
enum<string>

Was ein gelieferter Datensatz ist: signal (Payload signals[], ein Eintrag pro Signal) oder company (Payload companies[], ein Eintrag pro Unternehmen mit verschachtelten Signalen). Standard folgt detection_mode: signal_first → signal, company_first → company. Die Limits (max_records_per_trigger, max_daily_records) zählen diese Einheit.

Verfügbare Optionen:
signal,
company
Beispiel:

"company"

company_dedupe_days
integer

Ein Unternehmen erscheint höchstens in einer Lieferung pro so vielen Tagen, über alle Signaltypen des Monitors; ein innerhalb des Fensters geliefertes Unternehmen bleibt aus späteren Lieferungen draußen und seine späteren Signale im Fenster werden übersprungen, nicht aufgeschoben. 0 = aus. Standard: 0.

Erforderlicher Bereich: x >= 0
Beispiel:

30

is_newest_first
boolean

Die frischesten passenden Signale zuerst liefern. Bei einem Trigger- oder Tageslimit bleiben die neuesten Datensätze, und der Cursor des Monitors rückt trotzdem bis zur neuesten geholten Zeile vor, sodass ältere Zeilen übersprungen und nie nachgeliefert werden. Standard false (älteste zuerst, nichts übersprungen).

Beispiel:

true

max_daily_records
integer

Hartes Limit gelieferter Datensätze pro Kalendertag in der Zeitzone des Besitzers (0 = unbegrenzt). Gezählt in der Datensatzeinheit des Monitors über erfolgreiche Lieferungen; ein Trigger liefert höchstens das Restbudget, danach wartet der Monitor bis zum nächsten Tag, ohne seinen Cursor zu bewegen. Standard: 0.

Erforderlicher Bereich: x >= 0
Beispiel:

200

notification_email
string<email>

E-Mail-Adresse für Fehlerbenachrichtigungen des Monitors.

max_retry_per_trigger
integer
Standard:1

Maximale Wiederholungen pro Auslösung. Min: 0, Max: 3, Standard: 1.

Erforderlicher Bereich: 0 <= x <= 3
retry_delay_second
integer
Standard:1

Verzögerung zwischen Wiederholungen in Sekunden. Min: 1, Max: 5, Standard: 1.

Erforderlicher Bereich: 1 <= x <= 5
deep
boolean

Optional, wird nur mit query verwendet. Führt den Reflection-Durchlauf für höhere Interpretationsgenauigkeit aus (Standard true; verdoppelt in etwa die Interpretationslatenz). Auf false setzen für einen schnelleren Einzeldurchlauf.

Antwort

Erfolgreiche Antwort mit den Details des neu erstellten Monitors.

metadata
object
data
object
Zuletzt geändert am 4. September 2026