Skip to main content
Verfolgen Sie die Entwicklung des Pubrio Data Layer.

Releases 2026

v2.4.6 - People Search liest Abteilungen so, wie sie geschrieben sind (Okt 2026)

  • Behoben: People Search liefert für departments und department_functions mit einem Wert, den der Katalog nicht enthält, keine Personen, wie es management_levels bereits tat. Zuvor wurde der Filter verworfen, und Personen aller Abteilungen kamen als normales 200 zurück.
  • API: Werte für Abteilungen, Funktionen und Management-Ebenen werden in People Search und Job Search ohne Beachtung von Groß-/Kleinschreibung, Leerzeichen und Satzzeichen verglichen: information_technology wird als master_information_technology gelesen. Ein Wert, der keinen Eintrag vollständig benennt, wird als der eine Eintrag gelesen, der alle seine Wörter enthält: engineering wird als master_engineering_technical gelesen.
  • API: People Search akzeptiert person_locations als weiteren Namen für people_locations; metadata.renamed_fields meldet die Umbenennung.
  • API: Kontakt-Lookup - Einzeln und Kontakt-Lookup - Massenabfrage suchen per first_name + last_name + domain oder company, sobald ein Eintrag weder email noch phone hat. is_enable_similarity_search ist für diese Einträge nicht mehr nötig; es entscheidet jetzt nur, ob ein Eintrag, dessen E-Mail oder Telefon niemanden findet, zusätzlich anhand des Namens gesucht wird.
  • API: domain kann eine Website sein, etwa https://www.stripe.com/; sie wird als stripe.com gelesen.
  • Behoben: Ein Massen-Lookup von Einträgen mit Name + Domain ohne is_enable_similarity_search antwortete mit einer leeren peoples-Liste, als hätte niemand gepasst. Eine Massenanfrage, in der kein Eintrag eine E-Mail, ein Telefon oder Name + Domain/Unternehmen enthält, wird jetzt wie der Einzel-Lookup mit 400 abgelehnt.
  • Behoben: Derselbe Name + dasselbe Unternehmen, zweimal in einer Massenanfrage gesendet, wird als is_duplicate_input markiert und nur einmal berechnet, wie es bei E-Mail oder Telefon bereits der Fall war.
  • API: Jeder Treffer enthält match.input_index, die Position seines Eintrags in peoples, sodass sich Treffer ihren Zeilen zuordnen lassen, auch wenn manche Zeilen niemanden finden.
  • Behoben: Ein Lookup per Name durchsucht alle Unternehmenseinträge mit dieser Domain, sodass auch Personen gefunden werden, die mit einem zweiten Eintrag desselben Unternehmens verknüpft sind, und die Antwort kommt etwa doppelt so schnell.
  • API: Ähnliche Personen suchen liefert für jede Person einen similarity_score zwischen 0 und 1, und per_page bestimmt die Seitengröße.
  • Behoben: Die Referenzperson oder der Referenztitel legt nur fest, was ähnlich bedeutet. Jeder andere Filter, etwa people_locations oder domains, grenzt die Ergebnisse ein; zuvor kam die Referenz selbst zurück und die anderen Filter wurden ignoriert.
  • Behoben: Expansions-Übersicht antwortet mit 408, wenn sie nicht rechtzeitig abgeschlossen werden kann, statt mit einer leeren countries-Liste.
  • Behoben: Job Search functions und Advertisement Search reach_tiers antworten bei einem nicht vorhandenen Wert sofort mit null Zeilen; zuvor lief die Anfrage bis zur Zeitüberschreitung.
  • Neu: Enums & Constants — jeder feste Wert, den die API akzeptiert oder zurückgibt, auf einer Seite: Senioritätsstufen, Jobfunktionen, Anzeigenquellen und -formate, Reichweiten-Stufen, Publisher-Plattformen, Signaltypen, Management-Ebenen.
  • Neu: Suchleitfäden für Job Search, News Search und Advertisement Search — Filtertabellen, Antwort-Durchläufe und Copy-Paste-Rezepte.
  • API: Job Search dokumentiert functions, seniority_ranks, launch_dates, location_ids, created_at und is_ascending_order. Antwortzeilen deklarieren nun functions, seniority_rank, source_type, base_salary, experience_requirement, education_requirement und employment_type.
  • API: Advertisement Search dokumentiert active_dates, reach_tiers, exclude_source_types, created_at, advertisement_search_id und is_ascending_order. source_types wurde korrigiert — es filtert Ergebnisse (nicht nur Enrichment) und akzeptiert tiktok und apple. Zeilen deklarieren nun advertisement_format_normalized, advertiser, advertisement_url, is_company_matched und das total_impressions-Tripel; metadata dokumentiert applied_source_types, unsupported_source_types, coverage_notes und skipped_source_types.
  • API: News Search dokumentiert published_at, news_search_id und is_ascending_order und deklariert jedes Zeilenfeld einschließlich expansion_signals (zurückgegeben, wenn is_expansion_signal_available gesetzt ist — dies macht die Entfernung in v2.3.1 rückgängig, die vor der Einführung dieses Flags erfolgte).
  • API: People Search dokumentiert exclude_people_titles, exclude_people_locations, exclude_departments, exclude_department_functions und company_exclude_locations.
  • API: Company Search dokumentiert social_media und advertisement_status.
  • API: Jeder Search-Endpunkt dokumentiert nun metadata.ignored_fields — nicht erkannte Body-Schlüssel werden verworfen, nicht abgelehnt, und dort aufgelistet. Job, News und Advertisement Search deklarieren nun außerdem pagination und einen typisierten metadata-Block statt eines Freiform-Objekts.
  • Docs: Vier Schemas (job_exclude_locations, advertisement_target_locations, advertisement_exclude_target_locations und domain_search_ids bei Expansion Rankings) hatten eine Beschreibung neben einem $ref stehen, was OpenAPI 3.0 stillschweigend verwirft. Sie werden nun korrekt gerendert.
  • API: Expansion Signal Search (POST /expansions/signals/search) ist nun dokumentiert — fragen Sie die rohen, datierten Signalzeilen hinter der Stufe eines Unternehmens ab, statt der Unternehmen, zu denen sie aggregiert werden.
  • API: Expansion Lookup (POST /expansions/lookup) ist nun dokumentiert — das deterministische Gegenstück zu Expansion Search, das Ihre Filter nie automatisch lockert, für Dashboards und geplante Jobs, die reproduzierbare Ergebnisse benötigen.
  • API: Monitore, die expansions beobachten, haben nun ein dokumentiertes Filtervokabular und Webhook-Payload. Siehe Webhooks einrichten.
  • API: is_include_metadata ist bei Company Expansion Detail, Compare, Summaries und Rankings dokumentiert. API-Key-Traffic ist standardmäßig schlank — setzen Sie es auf true, um confidence_score und die vollständigen Modelldetails zu erhalten.
  • API: Expansion-Fehlercodes (40043, 40360, 40435, 40436) wurden zu den Statuscodes hinzugefügt.
  • Entfernt: Die Referenzseiten /companies/{jobs,news,advertisements}/export. Export liefert einen CSV-Anhang gegen ein separates data_export_credit-Guthaben und liefert nichts, was der entsprechende Search-Endpunkt nicht bereits als JSON liefert — verwenden Sie stattdessen Search mit Paginierung.
  • Entfernt: Die Referenzseite /people/enrichment, die einen nie veröffentlichten Endpunkt dokumentierte. Um eine Person anzureichern, rufen Sie People Lookup mit is_enrichment_available: true auf.
  • Docs: profile_id wurde aus jedem Request-Body entfernt. Ihr API-Key identifiziert bereits Ihren Workspace, und der Parameter wurde bei API-Key-Anfragen ohnehin ignoriert.
  • API: Die Suche nach ähnlichen Unternehmen und ähnlichen Personen dokumentiert nun den erforderlichen Referenz-Identifikator. Zuvor lieferte /companies/search/similar 41847 Missing parameter für jede dokumentierte Parameterkombination.
  • API: Company Enrichment dokumentiert die Arrays jobs, news, advertisements und similar_companies, die es zusammen mit dem Unternehmensdatensatz zurückgibt, und weist darauf hin, dass der Aufruf regelmäßig 30–60 Sekunden dauert.
  • API: Acht Endpunkte deklarieren nun das zurückgegebene metadata-Objekt der obersten Ebene, einschließlich des profile-Blocks mit credit, topup_credit und total_credit_cost.
  • API: Endpunkte zur Unternehmensidentifikation dokumentieren alle neun akzeptierten Identifikatoren und ergänzen tiktok_url, wantedly_url, tw104_url, rocketpunch_url, remember_url und youtrust_url.
  • Docs: 41847 Missing parameter — der häufigste Fehler der API — wurde zu den Statuscodes hinzugefügt.
  • Docs: Authentifizierung behandelt nun die User-Agent-Anforderung. Clients mit einem generischen User-Agent werden am Edge mit HTTP 403 und error code: 1010 blockiert, was leicht mit einem ungültigen API-Key verwechselt werden kann.
  • Docs: Rate Limit dokumentiert die von Profile Usage zurückgegebenen Nutzungs- und Kontingentfelder, einschließlich der Anwendung des Lizenz-Multiplikators durch total_max_*.
  • API: Expansion-Filter (stages, signal_types, signal_strengths, freshness, momentum, polarity) listen nun ihre erlaubten Werte auf, und jeder weist darauf hin, dass ein nicht erkannter Wert stillschweigend verworfen statt abgelehnt wird — bei manchen Parametern wird der Filter fallengelassen, bei anderen liefert er keine Treffer.
  • API: momentum akzeptiert advancing, steady und pulling_back. Die directions-Werte in der Expansion-Referenz (retreating, new) sind Antwortwerte in stage.direction und waren nie als Filter gültig.
  • API: News Insights korrigiert — mentions, topics, sources und top_source sind Integer-/String-Felder innerhalb von data.totals, keine Arrays der obersten Ebene. topics und sources sind Zählwerte unterschiedlicher Werte; die Listen der einzelnen Elemente sind category_breakdown und market_breakdown.
  • API: Advertisement Insights korrigiert — postings[] verwendet die abgekürzten Schlüssel r, m, ch, fo, n; reach_tiers[] ist ein {slug, label}-Katalog ohne Zählwerte; creatives[] dokumentiert alle zehn Felder einschließlich image_url, cta und has_video.
  • API: Die parameters-Schlüssel von Channel-Templates variieren je nach channel_type_slug — E-Mail-, LinkedIn- und Twilio-Templates tragen jeweils unterschiedliche Sätze.
  • Docs: Antwortfelder entfernt, die die API nicht zurückgibt: referral_code bei User, similarity_score bei Similar People, funding_status und crunchbase_url bei LinkedIn Company Lookup, expansion_signals bei News Search sowie occurs_at / occurs_until bei Expansion Signal Search.
  • Docs: Die Statuscode-Tabelle wurde aus der Fehlertabelle der API neu aufgebaut. Neun Codes waren falsch: 40075, 40076, 40091, 40092 und 40095 waren für Paginierungs- und Kontingentfehler dokumentiert, sind aber tatsächlich 41675, 41676, 41691, 41692 und 41695 bei HTTP 416 — und jede dokumentierte Nummer ist ein aktiver Code für etwas völlig anderes. 40003, 40602 und 40603 sind tatsächlich 40303, 40632 und 40633; 40099 existiert nicht.
  • Docs: HTTP 416 ist nun dokumentiert. Paginierungs- und Kontingentüberläufe liefern 416 mit einem 416xx-Code, niemals eine gekappte Ergebnismenge.
  • Docs: Die Monitor-Fehlerfamilie (40020–40035) wurde ergänzt, einschließlich 40021 — detection_mode kann nach Erstellung eines Monitors nicht mehr geändert werden.
  • API: per_page ist auf max_search_per_page Ihres Plans begrenzt (25 bei den meisten Plänen); 26 liefert HTTP 416. page ist auf max_search_page begrenzt. Beide Limits sowie jede andere Plan-Obergrenze werden von Profile zurückgegeben und sind nun in Rate Limit aufgeführt.
  • API: people_contact_types akzeptiert ausschließlich email-work, email-personal und phone. Ein nicht erkannter Wert wird nicht abgelehnt — er liefert HTTP 200 mit emails: null und Kosten von null Credits, was nicht von einer Person ohne Kontaktdaten zu unterscheiden ist.
  • API: Redemption-Antworten liefern null statt [] für emails und phones, wenn nichts gefunden wird.
  • API: Die create-Parameter für Channel-Templates sind nun dokumentiert — channel_node_id ist eine UUID aus Channel Template Types und bestimmt, welche parameters-Schlüssel gültig sind. delete nimmt numerische channel_template_id-Werte entgegen und entfernt jeweils eine Version.
  • API: Die Webhook-Validierung von Monitoren führt eine echte, signierte Zustellung durch; eine URL, die nur auf GET antwortet, schlägt weiterhin fehl, und details liefert den Antwort-Body des Upstream-Systems zurück.
  • Neue Funktion: Market Expansion API. Verfolgen Sie, welche Unternehmen in welche Märkte eintreten und wie weit sie dabei fortgeschritten sind — eine vierstufige Leiter (Exploring → Committing → Expanding → Scaling), aufgebaut aus realen Einstellungs-, Nachrichten-, Werbe-, Cloud-Infrastruktur- und Event-Signalen. Suchen Sie nach Korridor mit froms / tos, tauchen Sie in den Markteintritt eines einzelnen Unternehmens ein und vergleichen Sie Wettbewerber. Starten Sie mit dem Schnelleinstieg.
  • Neue Funktion: Suche in natürlicher Sprache. Übergeben Sie eine einfache englischsprachige query an Expansion Search („fintech companies expanding into the UK”), und Pubrio interpretiert sie in Filter — mit optionalen KI-Match-Erklärungen, die über is_explain_match auf den realen Signalen jedes Unternehmens basieren.
  • API: Ergebnisse verwenden nun standardmäßig eine Relevanzreihenfolge, die bestätigte Bewegungen (mehrere unabhängige Signaltypen) zuerst zeigt; übergeben Sie sort_by: "recent" für reine Aktualität.
  • API: Monitore können nun neben Jobs, Nachrichten und Werbung auch Expansion-Signale beobachten (signal_types: ["expansions"]), und ein Monitor kann über Monitor Interpret aus einem einfachen englischsprachigen Satz entworfen werden.
  • API: Der Monitor-Lebenszyklus ist nun ein einzelnes status-Feld (draft / active / paused / inactive), das die vorherigen is_active- / is_paused-Booleans in Anfragen und Antworten ersetzt.
  • Neue Funktion: Monitors. Automatisierte Signalerkennung mit Echtzeit-Zustellung — verfolgen Sie Stellenausschreibungen, Unternehmensnachrichten und Ad-Kampagnen über Millionen von Unternehmen hinweg, ohne eine eigene Polling-Pipeline zu bauen. Definieren Sie Filter einmal, und Pubrio scannt, reichert an und liefert passende Signale an Ihren Webhook, Ihre E-Mail oder Outreach-Sequence.
  • Neue Funktion: Zwei Erkennungsmodi. Wählen Sie zwischen Signal First (breites Markt-Scanning) und Company First (Verfolgung benannter Accounts), passend zu Ihrem Prospecting-Workflow.
  • Neue Funktion: Automatische Personenanreicherung. Jeder Monitor-Trigger kann automatisch Kontakte bei getroffenen Unternehmen finden und einlösen — mehrschichtige Anreicherung mit konfigurierbaren Filtern für Management-Ebene, Abteilung und Berufsbezeichnung.
  • API: 15 neue Monitor-Endpunkte hinzugefügt — vollständiges CRUD, Statistiken, Diagramme, Erkennungsprotokolle, Webhook-Validierung und Testverarbeitung. Siehe die Monitor-API-Referenz.
  • API: profile_id ist in Request-Bodys nicht mehr erforderlich. Der API-Key enthält nun Workspace-Informationen. Der Parameter wird aus Gründen der Abwärtskompatibilität weiterhin akzeptiert.
  • API: operationId, summary, description und tags wurden zu allen 59 API-Endpunkten hinzugefügt, um die Kompatibilität mit KI-Agenten und MCP-Tools zu verbessern.
  • Docs: llms.txt für die Auffindbarkeit durch KI-Crawler aktiviert.
  • Neue Funktion: KI Smart Lists (Beta). Nutzer können nun CSVs hochladen und in einer Tabellenoberfläche anzeigen, in der Pubrio fehlende Spalten automatisch ausfüllt.
  • Daten: 3 Millionen neue verifizierte Entitäten in der DACH-Region (Deutschland, Österreich, Schweiz) hinzugefügt.
  • API: Schnellere Antwortzeiten (Latenz um 200 ms reduziert) für den Endpunkt /enrich/company.
  • Neue Funktion: Ads Search Intelligence. Wir indexieren nun Ad-Transparenzzentren und Repositories für bezahlte Suche. Sie können jetzt sehen, ob ein Unternehmen Anzeigen schaltet, wo es Budget einsetzt und welche Keywords es anvisiert.
  • Verbesserung: Verbesserte „Tech Stack”-Erkennung für Unternehmen, die nicht standardisierte, lokalisierte Software in LATAM nutzen.

Archiv 2025: Das Partner-Jahr

2025 war geprägt von unseren wichtigen Ökosystem-Integrationen, die Pubrio-Daten in die Plattformen bringen, die Sie täglich nutzen.
  • Integration: Ottokit. Native Connector für autonome Agenten-Workflows eingeführt.
  • Integration: Databar. Pubrio als verifizierten Anbieter im Databar-Marketplace für No-Code-Recherche hinzugefügt.
  • Integration: Stripo. „Push to Sequence”-Funktionalität eingeführt, die es Design-Teams ermöglicht, HTML-Templates direkt mit Pubrio-Workflows zu synchronisieren.
  • Funktion: Dynamische Variableninjektion. Ermöglicht die Auflösung generischer Platzhalter in Templates mit Echtzeit-Pubrio-Daten beim Versand.
  • Integration: Clay Native Integration. Wurde zum Standardanbieter im Clay-Enrichment-Menü.
  • Daten: Die Abdeckung der „unsichtbaren 70 %” um 15 neue lokale Register im asiatisch-pazifischen Raum erweitert.
Zuletzt geändert am 2. Oktober 2026