Organisationen, Anwendungen und Umgebungen

Eine Organisation umfasst Ihr Team und Ihre Abrechnung; Anwendungen enthalten Workflows und API-Schlüssel, und jede ist entweder Live oder Sandbox. Diese Struktur richtig zu verstehen verhindert die meisten verwirrenden Verhaltensweisen.

Verfasst vom Didit-Support · Aktualisiert am 15. September 2026

#Die beiden Ebenen

Organisation ist Ihr Konto. Sie umfasst:

• Ihr Team und dessen Rollen
• Ihr Abrechnungsguthaben und Ihre Rechnungen
• Ihr Audit-Protokoll
• Alle Ihre Anwendungen

Anwendung ist ein Arbeitsbereich innerhalb der Organisation. Sie umfasst:

• Eigene Workflows
• Einen eigenen API-Schlüssel
• Eigene Webhook-Ziele
• Eine eigene Datenaufbewahrungsrichtlinie
• Einen Modus: live oder sandbox

Wechseln Sie zwischen Anwendungen über das Dropdown oben in der Konsole.

#Warum das wichtiger ist, als es aussieht

Fast jede Meldung der Art "ich habe es geändert und nichts ist passiert" lässt sich auf diese Struktur zurückführen:

• Sie haben einen Workflow in Anwendung A bearbeitet, während Ihre Sessions unter Anwendung B laufen.
• Sie haben ein Webhook-Ziel zu einer Anwendung hinzugefügt und Ereignisse von einer anderen erwartet.
• Sie rufen mit einem Schlüssel einer anderen Anwendung auf als der, zu der die angesprochene Ressource gehört, und erhalten einen 404 oder 403 für etwas, das eindeutig existiert.

Bevor Sie irgendetwas anderes debuggen, bestätigen Sie die Anwendung. Siehe API-Fehler und was sie bedeuten.

#Live und Sandbox sind getrennte Anwendungen

Es gibt keinen Testmodus-Schalter innerhalb einer Live-Anwendung. Der Modus wird pro Anwendung gewählt, Testen bedeutet also, eine zweite Anwendung im Sandbox-Modus zu erstellen und deren Schlüssel zu verwenden.

Genau das ist der Sinn dieser Trennung: Testverkehr und Produktivdaten vermischen sich nie, und ein Sandbox-Schlüssel kann nicht versehentlich echte Credits ausgeben. Siehe Testen in der Sandbox.

#Wie viele Anwendungen sollten Sie haben?

Mindestens eine Live- und eine Sandbox-Anwendung. Darüber hinaus teilen Sie nach allem auf, was eine eigene Konfiguration oder eigene Isolation benötigt:

• Pro Produkt, wenn verschiedene Produkte unterschiedliche Workflows und unterschiedliche Webhook-Endpunkte benötigen.
• Pro Umgebung, wenn Sie mehr als eine Pre-Production-Umgebung betreiben.
• Pro Marke, wenn Sie Verifizierung unter mehreren Marken mit unterschiedlichem Styling anbieten.
• Pro Aufbewahrungsrichtlinie, da die Aufbewahrung pro Anwendung konfiguriert wird.

Was sich nicht pro Anwendung aufteilt: Ihr Guthaben, das auf Organisationsebene liegt. Jede Anwendung greift auf dieselben Credits zu.

#Weitere Anwendungen erstellen

Weitere Anwendungen werden in der Konsole erstellt. Wenn die Option fehlt, oder Sie eine Anwendung über die API statt über die Konsole erstellen müssen, ist das eine Frage der Berechtigung auf Kontoebene, die es sich lohnt, beim Support zu erfragen, statt sie zu umgehen - besonders bei einer zweiten Live-Anwendung, wo die Antwort von Ihrem Plan abhängen kann.

#Mehrere Organisationen

Die E-Mail-Adresse einer Person gehört jeweils zu einer Organisation, und es gibt keine Möglichkeit, Unterorganisationen oder Unterkonten unter Ihrer anzulegen. Wenn Sie mehrere eigene Kunden bedienen, ist die unterstützte Struktur eine Anwendung pro Kunde innerhalb Ihrer einzigen Organisation: jede Anwendung hat ihre eigenen Workflows, ihr Branding, ihre API-Schlüssel, Ergebnisse und Nutzungsberichte, vollständig von den anderen getrennt, während die Abrechnung auf Organisationsebene bleibt.

#Didit weiterverkaufen

Wenn Sie Didit in Ihr eigenes Produkt bündeln und Ihren Kunden berechnen möchten, ist das das Reseller-Modell. So funktioniert es, in den Worten, die der Support jedem gibt, der fragt:

• Vorausbezahltes Guthaben. Ein Mindesterstkauf von 5.000 USD, vorausbezahlt, mit einer einjährigen Vereinbarung. Das Guthaben verfällt nie, liegt auf Organisationsebene und wird über alle Endkunden verbraucht, die Sie anbinden, und es enthält einen Mengenrabatt, der mit dem Betrag steigt.
• Das Dashboard bauen Sie. Sie integrieren die Didit-API in Ihr eigenes Frontend, und Ihre Kunden verwalten dort ihre Workflows, ihr Branding und ihre Rollen. Didit stellt keine White-Label-Kopie der Business Console bereit; die Verifizierungsbildschirme, die Ihre Endnutzer sehen, können Ihre Marke tragen (siehe White Label), die Konsole nicht.
• Ihre Marge gehört Ihnen. Sie legen den Preis fest, den Ihre Kunden zahlen. Didit berechnet Ihnen pro abgeschlossener Funktion zu den für die Laufzeit festgelegten Stückpreisen.
• Kein Programm für lokale Partner. Didit führt Demos, Onboarding und Support direkt mit den Kunden durch und sucht keine Vertriebs- oder Implementierungspartner.

Wenn Sie den Weiterverkauf lieber nicht übernehmen möchten, nutzen Sie stattdessen die Empfehlungsoption: öffnen Sie in der Seitenleiste der Business Console Empfehlungen, akzeptieren Sie die Programmbedingungen und teilen Sie Ihren Link. Sie erhalten 10 % Provision auf jede Bareinzahlung einer empfohlenen Organisation, 36 Monate lang ab deren erster Einzahlung, als Didit-Guthaben nutzbar oder nach der Reifefrist per Banküberweisung auszahlbar - ohne Liefer- oder Supportpflichten. Sie können Ihre Integration im kostenlosen Kontingent bauen und testen, bevor Sie sich für eines von beiden entscheiden.

#Eine Anwendung löschen

Das Löschen einer Anwendung entfernt deren Workflows und Konfiguration. Ihre Verifizierungsdaten folgen der Aufbewahrungsrichtlinie und den Löschregeln für diese Daten, nicht dem Lebenszyklus der Anwendung - wenn Ihr Ziel also ist, Kundendaten zu löschen, löschen Sie die Daten explizit, statt anzunehmen, dass das Entfernen der Anwendung das übernimmt. Siehe Sessions und personenbezogene Daten löschen.

#Alles ist zuordenbar

Jeder API-Aufruf zeichnet auf, zu welcher Anwendung er gehörte, im Audit-Protokoll, für 365 Tage. Das macht eine Struktur mit mehreren Anwendungen überprüfbar statt nur ordentlich. Siehe Audit-Protokolle nutzen.