Erweiterungspunkte für die Lead-Verarbeitung

Diese Seite behandelt die Lead-Verarbeitung ausschliesslich auf Integrationsebene. Interne Hook-Namen, Payload-Strukturen, Berechtigungs-IDs und Details zur Webhook-Signierung sind Implementierungsdetails und werden hier nicht veröffentlicht.

Was die Lead-Verarbeitung tut

Wenn ein Besucher ein Kontaktformular absendet, das mit einem Fahrzeug verknüpft ist, speichert das Plugin den Lead, benachrichtigt die konfigurierten Empfänger und leitet den Lead optional über den ausgehenden Webhook-Mechanismus des Plugins an ein externes System weiter. Die Empfänger, die Versandmethode und die für ausgehende Webhooks verwendete Authentifizierung werden in der Admin-Benutzeroberfläche des Plugins konfiguriert.

Integration mit nachgelagerten Systemen

Der unterstützte Weg zur Weiterleitung von Leads an ein CRM oder Marketing-Tool besteht darin, den ausgehenden Webhook des Plugins über die Admin-Benutzeroberfläche zu konfigurieren. Interne Hook-Namen, die Payload-Struktur und das zur Authentifizierung ausgehender Webhook-Aufrufe verwendete Signierungsverfahren können sich zwischen den Versionen ändern; überprüfen Sie Ihren nachgelagerten Empfänger bei der Konfiguration anhand der aktuellen Plugin-Version und codieren Sie keine internen Action- oder Filter-Namen fest in Ihre Integration ein.

Unterstützte öffentliche Integrationsschnittstellen

Bevorzugen Sie bei der Integration mit dem Plugin diese stabilen Schnittstellen:

• Die Admin-Einstellungen des Plugins in der WordPress-Benutzeroberfläche.
• Die dokumentierten Shortcodes.
• Template-Overrides auf Theme-Ebene, wie in Template System And Overrides beschrieben.
• Die allgemeine Entwickler-Übersicht zur Orientierung.

Interne Klassennamen, Option-Keys, Datenbanktabellen, REST- und AJAX-Endpunkte, Cron-Hook-Namen, Berechtigungs- und Nonce-IDs sowie die Release- und Update-Infrastruktur werden als Implementierungsdetails behandelt. Sie können sich zwischen den Versionen ohne vorherige Ankündigung ändern und sind nicht Bestandteil des öffentlichen Integrationsvertrags.

Stabilitäts- und Änderungsrichtlinie

Alles, was oben nicht als unterstützte öffentliche Schnittstelle aufgeführt ist, gilt als internes Implementierungsdetail. Interne APIs, das Speicherlayout und Sicherheitsimplementierungen können sich zwischen den Versionen ändern. Verlassen Sie sich in Drittanbieter-Code, Themes oder externen Systemen nicht auf diese Details. Direkte Schreibzugriffe auf die Datenbank werden nicht unterstützt.

Hinweis zur öffentlichen Dokumentation. Diese Seite bietet nur eine allgemeine Integrationsübersicht. Interne Implementierungsdetails, private APIs, Speicherinterna und sicherheitsrelevante Release-Infrastrukturen werden separat gepflegt und sind nicht Bestandteil der öffentlichen Dokumentation. Unterstützte Integrationsschnittstellen sind die dokumentierten Shortcodes, Template-Overrides, die Einstellungs-Benutzeroberfläche und alle in diesem Abschnitt explizit veröffentlichten Erweiterungspunkte.