Personenprofile per API: Geschäftsführung, Gesellschafter, Vorstand und Prokura mit einem Call

Eine konkrete Person aus dem deutschen Handelsregister recherchieren – das war bisher Klickarbeit. LinkedIn-Suche, Abgleich mit Impressum, Quercheck im Handelsregister, im Zweifel noch ein Anruf, weil zwei Personen denselben Namen haben. Genau diesen Workflow löst der neue Endpoint /api/v1/fetch-person aus dem April-2026-Release ab. Ein Call – zurück kommt ein KI-angereichertes Personenprofil, das die offiziellen Handelsregister-Rollen mit öffentlichen Webdaten kombiniert. Und zwar nicht nur für Geschäftsführer:innen, sondern für jede Rolle, die im Register auftaucht: Vorstand, Aufsichtsrat, Prokuristen, natürliche Gesellschafter:innen, persönlich haftende Gesellschafter, Liquidatoren. Plus optional die Beteiligungen dieser Person an anderen Firmen.

Was /api/v1/fetch-person tatsächlich zurückliefert

Der Endpoint führt zwei Datenwelten zusammen, die du sonst getrennt recherchieren musst:

• Rollen aus dem Handelsregister. Alle Funktionen, in denen die Person als natürliche Person auftaucht – mit Rollen-Label (z. B. MANAGING_DIRECTOR, BOARD_MEMBER, AUTHORIZED_REPRESENTATIVE), Firma, entity_id, Start- und ggf. End-Datum.
• Anreicherung aus dem öffentlichen Web. Kurze Biografie, Fachgebiete, Wohnort, Kontaktdaten (sofern öffentlich), LinkedIn, GitHub, weitere Affiliations.

Damit deckt der Endpoint praktisch jede Rolle ab, die mit einer eingetragenen Firma verbunden ist:

• Geschäftsführung (GmbH/UG)
• Vorstand und Aufsichtsrat (AG/SE/eG)
• Prokuristen (alle eintragungspflichtigen Rechtsformen)
• Natürliche Gesellschafter:innen (vor allem über die Gesellschafterliste)
• Persönlich haftende Gesellschafter (OHG/KG)
• Liquidatoren und Insolvenzverwalter

Der ai_search-Modus ist auf diesem Endpoint immer aktiv. Die 15 Credits Grundkosten enthalten die KI-Anreicherung bereits – es gibt keinen separaten Schalter.

Der Disambiguierungs-Trick: warum organization_q Pflicht ist

Wenn du in einer normalen Personensuche „Thomas Müller" eingibst, bekommst du Hunderte von Treffern. Genau dieses Problem löst das API-Design elegant: organization_q ist nicht optional. Du musst neben person_q immer auch einen Unternehmenskontext angeben (min. 2 Zeichen).

Dieser Pflichtparameter ist mehr als nur Komfort – er ist die zentrale Architekturentscheidung des Endpoints. Statt eine Personensuche zu sein, ist /api/v1/fetch-person eine Personensuche im Kontext einer konkreten Firma. Wer das verinnerlicht, baut die richtigen Workflows:

• Du hast eine Firma identifiziert (z. B. via /api/v1/search-organizations oder direkt aus deinem CRM) und willst eine bestimmte Person daraus profilen → perfekter Anwendungsfall.
• Du hast nur einen Namen ohne Firma → erst Firma klären, dann fetch-person.

Praktisch heißt das: Die API liefert dir keine 100 Müllers in einer Liste zurück, sondern den einen Thomas Müller, der bei der angegebenen Firma als Geschäftsführer geführt wird. Das ist nicht nur weniger Datenrauschen – das ist auch deutlich datenschutzfreundlicher.

feature=shareholdings: was diese Person sonst noch hält

Mit dem optionalen feature=shareholdings (+5 Credits, nur wenn Daten geliefert werden) bekommst du die umgekehrte Perspektive: An welchen Gesellschaften ist diese Person selbst beteiligt? Pro Beteiligung mit Quote, Einlage und Stichtag.

Das ist der Datenpunkt, den du sonst über mühsame manuelle Recherche aus mehreren Gesellschafterlisten zusammensuchen müsstest. Für M&A-Research, Sanktions-Propagierung und Personen-Risikobewertung ist das oft entscheidend: Eine Person, die formal nur Geschäftsführerin einer kleinen Holding ist, hält über ihre Beteiligungen vielleicht maßgebliche Anteile an drei weiteren Firmen.

Praxis-Beispiel: ein Aufruf, ein strukturiertes Profil

curl -X GET 'https://handelsregister.ai/api/v1/fetch-person?person_q=Max%20Mustermann&organization_q=Beispielwerk%20Analytics%20GmbH&features=shareholdings' \
     -H 'x-api-key: YOUR_API_KEY'

Highlights aus der Antwort (gekürzt):

• name_parts: zerlegter Name mit canonical_name für Datenbank-Joins
• bio: kurze Biografie aus Webquellen
• expertise: Themen-Tags (z. B. Produktentwicklung, KI, Finanzen)
• profiles.linkedin / profiles.github: Direktverweise auf öffentliche Profile
• handelsregister_roles: alle eingetragenen Funktionen mit start_date und end_date
• shareholdings.holdings.current: aktive Beteiligungen mit Quote, Einlage, Adresse, HR-Eintrag der gehaltenen Gesellschaft
• affiliations: weitere Verbindungen, die nicht im Handelsregister stehen

Das ist die Datendichte, für die du sonst drei bis fünf separate Recherche-Schritte gebraucht hättest.

Vier Use Cases, vier Rollen

Die Bandbreite des Endpoints zeigt sich am besten an konkreten Workflows:

1) Sales / BD: Signing Authority identifizieren. Bei B2B-Deals brauchst du oft schnell die unterschriftsberechtigte Person – nicht „irgendeine Kontaktperson". Mit einem fetch-person-Call auf den Geschäftsführer oder die Prokuristin (siehe dazu auch unsere Prokura-Anleitung) bekommst du Namen, LinkedIn-Profil und Rollen-Historie sofort strukturiert. Spart pro Lead ~10 Minuten LinkedIn-Suche.

2) M&A / Investment Research: natürliche Gesellschafter:innen. Wenn eine Zielfirma zu 40 % einer Privatperson gehört, willst du wissen, wer das ist und was sie sonst noch hält. fetch-person mit feature=shareholdings liefert in einem Call: Profil + komplettes Beteiligungsportfolio. Das ist der Mehrwert gegenüber einer reinen UBO-Abfrage – siehe auch die UBO-Mechanik im Detail.

3) Compliance: UBO-Liste auf Personenebene anreichern. Aus einem UBO-Lookup hast du Namen + Quote. Was du noch brauchst, um eine PEP- oder Sanktionsprüfung sauber durchzuführen: Geburtsdatum, Wohnort, weitere Rollen, öffentliche Web-Footprints. Genau das liefert fetch-person. Ergänzung statt Ersatz für deine Watchlist-Screening-Tools.

4) Executive Research / Recruiting: Vorstands- und Aufsichtsratsprofile. Für Talent-Mapping in regulierten Branchen (Banken, Versicherungen, Asset Management) musst du Vorstand und Aufsichtsrat einer Firma profilieren. Statt 15 LinkedIn-Tabs zu öffnen: ein API-Call pro Person mit derselben Firma als organization_q, Daten landen strukturiert im CRM.

Das Schöne: Es ist immer derselbe Endpoint, immer derselbe Datenshape. Was sich ändert, ist nur die Rolle, auf die du fokussierst.

Kosten, Limits und Verfügbarkeit

• Grundkosten: 15 Credits pro Abfrage – KI-Anreicherung ist enthalten.
• shareholdings: +5 Credits, nur wenn die API tatsächlich Beteiligungen findet (Fair Use).
• Rate Limit: 60 Calls/min (gemeinsam mit den anderen Endpoints).
• Verfügbarkeit: in den Plänen Plus, Pro und Max enthalten.
• Authentifizierung: x-api-key-Header (empfohlen), Query-Parameter oder Bearer Token – alles wie auf /api/v1/fetch-organization.

Für eine Massenanreicherung von mehreren Hundert Personen kalkuliere also ungefähr 3,3 Credits pro Person bei einem Plus-Plan – günstiger als ein einziger LinkedIn Sales Navigator Seat-Tag.

Edge Cases, die jeder Workflow sieht

• Sehr häufige Namen. Selbst mit organization_q kann ein Name innerhalb einer großen Firma mehrdeutig sein (zwei „Schmidt" im Vorstand). Plane einen optionalen zweiten Filter (Vorname plus eindeutige Mittelinitiale) und prüfe handelsregister_roles, ob die Rolle zur Erwartung passt.
• Ehemalige Rollen. Die API liefert auch beendete Rollen (end_date gesetzt). Für Sales/Recruiting ist das oft Rauschen – filtere serverseitig nicht, sondern auf deiner Seite, damit du die Historie zur Hand hast.
• Auslandsbezug. Personen, die ausschließlich Rollen in ausländischen Gesellschaften halten, sind nicht im deutschen Handelsregister. Erwartung: dünne Antwort, hauptsächlich Webdaten. Markiere solche Cases als „nur Webquellen".
• DSGVO-Hygiene. fetch-person liefert nur öffentlich verfügbare Daten – aber Verarbeitung bleibt deine Verantwortung. Dokumentiere Rechtsgrundlage (Art. 6 DSGVO), Speicherzweck und Löschfristen. Für KYC-Cases ist die Grundlage meist Art. 6 Abs. 1 lit. c (rechtliche Verpflichtung GwG); für Sales/BD eher Art. 6 Abs. 1 lit. f (berechtigtes Interesse) mit Interessenabwägung.
• Cache-TTL. Personendaten sind volatiler als Firmendaten (Wohnort, Rollen). Setze die TTL auf maximal 30 Tage; für KYC-relevante Profile besser 7 Tage.

Recap

/api/v1/fetch-person ist kein Geschäftsführer-Lookup – es ist ein Rollen-agnostischer Personenprofile-Endpoint im Firmenkontext, der Handelsregister-Rollen und KI-angereicherte Webdaten in einem Call zusammenführt. Die Pflicht-Disambiguierung über organization_q macht ihn präzise und datenschutzfreundlich; feature=shareholdings öffnet zusätzlich die Beteiligungsperspektive.

Für vier sehr unterschiedliche Zielgruppen – Sales, M&A, Compliance, Executive Research – ersetzt ein einziger Endpoint einen ganzen Stack an manueller Recherchearbeit. Wenn du den Compliance-Agent-Ansatz mit Tool-Calling baust, ist fetch-person praktisch automatisch das dritte Tool neben search-organizations und fetch-organization.

Probiere es zuerst gegen drei bis fünf Personen aus deinem aktuellen Pipeline – einmal Geschäftsführer:in, einmal Prokurist:in, einmal Gesellschafter:in mit Beteiligungen. Genau in dem Vergleich siehst du, wo der Endpoint deinen Stack heute schon abkürzt.