Plattform-Embedding: eine Integration, viele Kunden

Sie sind eine Plattform — ein CRM, ein ERP, ein Branchen-SaaS — und betten Mildport einmal ein. Aber die Dateien importieren Ihre Kunden, jeder mit eigenen Daten, eigenem Spaltenvokabular, eigenen Compliance-Anforderungen und einer eigenen Vorstellung davon, wie viel KI-Unterstützung er möchte. Diese Seite erklärt die zwei Wege, sie zu bedienen, was jeder garantiert und wie Sie wählen.

Die Faustregel

Stellen Sie eine Frage: müssen Ihre Kunden voneinander isoliert sein — oder nur unterscheidbar?

Unterscheidbar → eine Lizenz, und Sie übergeben bei jedem Import Ihre eigene Kundenreferenz. Günstig, kein Provisioning.
Isoliert → jeder Kunde bekommt einen eigenen Tenant (eigenen Lizenzschlüssel). Jeder erhält ein privates Vokabular, private Einstellungen, private Zustellziele und private Limits.

Alles Weitere auf dieser Seite sind Details zu diesen zwei Optionen.

Option 1 — eine Lizenz, Ihre Kundenreferenz

Ihre Integration behält einen einzigen Lizenzschlüssel. Bei jedem Import übergeben Sie Ihren eigenen Bezeichner für den Endkunden — eine opake Zeichenkette Ihrer Wahl, in der REST-API externalId genannt:

Sie wird mit dem Import gespeichert und bei Lesezugriffen und Apply-Zustellungen zurückgegeben — Ihr Backend weiß immer, zu welchem Ihrer Kunden ein Datensatz gehört.
Das Widget kann jedem Kunden eine andere Teilmenge Ihres Feldkatalogs zeigen — entweder per Inline-Felddefinition pro Embed, oder über einen veröffentlichten Katalog mit gespeichertem Projekt-Ausschnitt (Attribut catalog-project; siehe Zielkataloge).
Das Widget-Verhalten (Formate, PDF-Modus, Beispieldaten, Review-Optionen) ist Konfiguration des jeweiligen Embeds und kann sich damit schon heute pro Kunde unterscheiden — siehe Widget konfigurieren.

Was diese Option nicht leistet: sie ist ein Etikett, keine Wand. Alle Kunden teilen ein gelerntes Mapping-Vokabular, einen Satz KI-Einstellungen, eine Webhook-Zielliste und einen Nutzungspool mit gemeinsamen Limits. Das Filtern von Lesezugriffen nach Ihrer Referenz liegt in Ihrer Verantwortung. Das ist das branchenübliche „Metadaten-Echo“-Muster — gut, um Posteingänge zu trennen, ungeeignet, wenn zwischen Kunden Datenschutz- oder Budgetgrenzen liegen müssen.

Option 2 — ein Tenant pro Kunde

Aus Ihrem Kunden-Panel können Sie zusätzliche Tenants anlegen, jeder mit eigenem Lizenzschlüssel, und jedem Ihrer Kunden einen widmen. Jeder solche Tenant ist ein vollwertiger, hart isolierter Mildport-Tenant:

Privates gelerntes Vokabular. Bestätigt ein Kunde, dass Zahlungsziel Payment terms bedeutet, gehört dieses Wissen ihm allein — es taucht nie im Import eines anderen Kunden auf. (Wie das Lernen funktioniert: wie das Matching entscheidet.)
Private Einstellungen und Features. KI-Unterstützung kann für einen Kunden an und für einen anderen aus sein — auch aus Compliance-Gründen — denn Features reisen in der signierten Lizenz jedes Kunden.
Private Zustellziele. Jeder Tenant registriert eigene Apply-Webhooks — die Zeilen jedes Kunden können an einen anderen Endpunkt geliefert werden (Webhooks).
Private Limits und Nutzung. Zeilenlimits, Rate-Limits und KI-Budgets gelten pro Tenant, und Ihr Panel zeigt Nutzung und Aktivität pro Kunde — wer wie viel importiert hat, wer das KI-Budget verbraucht hat — ohne Rekonstruktionsarbeit auf Ihrer Seite.

Die Schlüssel sind offline verifizierbare signierte Tokens; nichts an diesem Aufbau „telefoniert nach Hause“, und er funktioniert in der Cloud wie selbst gehostet identisch (Self-Hosting).

Die Wahl auf einen Blick

Ihr Kunde braucht…	Eine Lizenz + Referenz	Tenant pro Kunde
Getrennte Posteingänge / „wessen Datensatz?“	✅	✅
Einen kleineren Ausschnitt des Feldkatalogs	✅	✅
Unterschiedliches Widget-Verhalten	✅	✅
KI für manche an, für andere aus	—	✅
Privates Mapping-Vokabular	—	✅
Eigenen Zustell-Endpunkt	—	✅
Eigene Limits, eigene Nutzungszeile, Budget	—	✅

Mischen ist normal: viele Plattformen starten mit einer Lizenz während der Integration und heben größere Kunden beim Onboarding auf dedizierte Tenants.

Betriebshinweise

Einen Kunden-Tenant anzulegen ist heute eine Panel-Aktion; wenn Sie Kunden programmatisch onboarden und Tenants aus Ihrem eigenen Flow erzeugen möchten, sprechen Sie uns an — ein aktives Entwicklungsfeld des Produkts.
Schlüssel lassen sich pro Kunde rotieren, ohne andere zu berühren.
Die Nutzung im Panel ist pro Tenant und Monat; Apply-Zustellungen tragen die Tenant-Identität — Ihr Rebilling kann auf beidem aufbauen.

Weiter: Widget installieren oder wie es funktioniert für das Gesamtbild der Zustellung.