White-label-URL-Shortener: Was White-Label wirklich bedeutet

White-Label ist eines jener Wörter, das jeder Link-Shortener-Anbieter auf seiner Preisseite verwendet und das fast keiner von ihnen definiert. Das Versprechen lautet: Sie können ihr Produkt als Ihres weiterverkaufen — Ihre Domain auf den Kurzlinks, Ihr Logo im Dashboard, Ihre Rechnung auf der Kreditkarte des Kunden. Die Realität ist meist, dass ein oder zwei dieser Dinge zutreffen und der Rest ein Screenshot ist.

Dieser Beitrag ist die ausführliche Definition. Vier Achsen, die eine White-Label-Funktion abdecken muss, anbieterweise, wo die Lücken tendenziell liegen, und die operative Realität des Betriebs eines Branded-Link-Produkts auf der Infrastruktur eines anderen. Die Zielgruppe sind Agenturen und SaaS-Unternehmen, die einen URL-Shortener in ihr eigenes Produkt integrieren möchten, ohne die Redirect-Schicht selbst aufzubauen. Der Bitly-Alternativen-Eckpfeiler behandelt die breitere Feature-Lücke; dieser Beitrag konzentriert sich auf den White-Label-Teil.

Die vier Achsen echter White-Label-Lösungen#

White-Label als Begriff bedeutet für sich genommen nichts. Die sinnvolle Frage lautet: Welche Oberflächen tragen die Marke des Anbieters und welche tragen Ihre? Vier Oberflächen sind relevant, in ungefährer Reihenfolge, wie oft ein Kunde sie bemerkt.

Domain. Die Kurzlink-URL selbst. s.ihre-agentur.de/abc123 statt bit.ly/abc123 oder s.elido.me/abc123. Dies ist die Oberfläche, die die meisten Anbieter richtig hinbekommen, weil es die Oberfläche ist, nach der jeder Kunde zuerst fragt. Sie ist auch die einfachste, weil DNS + On-Demand TLS das Problem in ein paar Minuten löst. Das Custom Domains Walkthrough erklärt den zugrunde liegenden Mechanismus.

Dashboard. Die Oberfläche, in die sich Ihr Kunde einloggt. Trägt sie Ihr Logo, Ihre Farben, Ihre Domain (links.ihre-agentur.de)? Kann der Kunde sein Passwort zurücksetzen, ohne eine E-Mail von [email protected] zu erhalten? Kann er Teammitglieder einladen, ohne den Namen des Anbieters irgendwo in der E-Mail-Betreffzeile zu sehen? Etwa 60% der selbst beschriebenen White-Label-Produkte scheitern an einem dieser Tests.

Abrechnung und Identität. Wer zahlt der Kunde, und wer kontrolliert die Benutzerkonten? Wenn Ihr Kunde einen Vertrag mit Ihnen abschließt, jeden Monat Ihre Rechnung sieht und sein Passwort gegen Ihren IdP zurücksetzt, ist das White-Label echt. Wenn er mit Ihnen unterschreibt, aber direkt beim Anbieter zahlt und Anmelde-E-Mails von der Domain des Anbieters erhält, handelt es sich um ein Partner-Programm-Rebadge, kein White-Label. Hier scheitern die meisten Anbieter stillschweigend.

API und Integrationen. Wenn der Entwickler Ihres Kunden Ihre API-Dokumentation liest, sieht er die API des Anbieters oder Ihre? Stammen die Webhook-Signaturen von Ihrer Domain oder der des Anbieters? Wenn er sich mit Zapier oder HubSpot verbindet, wird Ihre oder die des Anbieters erwähnt? Diese Achse ist die am weitesten unten im Trichter und die am leichtesten zu übersehen, bis Sie Ihren ersten Entwickler-Kunden haben, der fragt, warum er drei Sätze von Dokumentationen lesen muss, um zu integrieren.

Über diese vier Achsen hinweg fallen Anbieter in drei grobe Kategorien: Domain-only (der günstigste Tarif — Sie erhalten höchstens eine benutzerdefinierte Kurzdomain und ein co-branded Dashboard), teilweises White-Label (Domain + Dashboard + manchmal Login-E-Mails) und vollständiges White-Label (alle vier, mit kontrollierbarem API- und Integrations-Branding). Die Preise spiegeln die Kategorie wider — Domain-only beginnt bei etwa 50 $/Monat, vollständiges White-Label beginnt bei 500 $/Monat und geht für Enterprise-Pläne in die Tausende.

Domain: Die Oberfläche, die einfach richtig zu machen ist#

Benutzerdefinierte Kurz-Domains sind selbstverständlich. Der Anbieter veröffentlicht ein CNAME-Ziel, Sie zeigen Ihr DNS darauf, der Anbieter stellt ein TLS-Zertifikat über Let's Encrypt aus und bedient Traffic mit Ihrer Domain in der URL. Der Mechanismus ist bei jedem Anbieter, der dies unterstützt, identisch: Caddys On-Demand TLS oder gleichwertig für Anbieter, die auf verschiedenen Stacks aufgebaut sind.

Die Stolpersteine sind operativer, nicht technischer Natur:

• DNS-Apex-Einschränkungen. Wenn Sie ihre-agentur.de selbst als Kurzdomain möchten (nicht s.ihre-agentur.de), lehnen die meisten DNS-Anbieter den CNAME ab, weil die DNS-Spezifikation CNAME-Records am Apex verbietet. Cloudflares CNAME-Flattening umgeht dies; OVH und Route53 erfordern stattdessen einen ALIAS- oder ANAME-Record. Der Anbieter kann das nicht für Sie lösen.
• Zertifikats-Transparenz-Leck. Öffentliche CT-Logs veröffentlichen jedes Let's Encrypt-Zertifikat. Wenn Ihre Kunden empfindlich darauf reagieren, dass „diese Domain auf der gleichen Hosting-Infrastruktur wie Unternehmen X ist" — was selten, aber bei Enterprise nicht null ist — sind das Informationen, die die CT-Logs preisgeben. Es gibt keine Möglichkeit, dies zu unterdrücken, abgesehen vom Betrieb eines eigenen ACME-Issuer-Setups.
• Subdomain-Kontingent. Einige Anbieter begrenzen die Anzahl der benutzerdefinierten Domains pro Konto auf niedrigeren Tarifen. Wenn Sie beabsichtigen, jedem Ihrer Kunden eine eigene Subdomain zu geben (kunde-1.short.ihre-agentur.de, kunde-2.short.ihre-agentur.de), bestätigen Sie das Kontingent vor der Unterzeichnung.

Der Custom Domain TLS Post behandelt den Ausstellungsmechanismus im Detail. Die relevante Feature-Seite ist /features/custom-domains.

Dashboard: Wo die Lücken normalerweise liegen#

Ein Custom-Domain-Dashboard ist schwieriger als es klingt. Der Anbieter muss seine UI unter Ihrer Domain bedienen, mit Ihrem Logo, Ihrem Farbschema und Ihrem Favicon, während er Benutzer gegen seinen Identitätsspeicher authentifiziert und API-Aufrufe gegen sein Backend bedient. Die Teile, die aufeinander abgestimmt sein müssen:

• DNS zeigt auf den UI-Hostname des Anbieters, getrennt vom Redirect-Tier. Die meisten Anbieter verwenden eine Subdomain wie app.ihre-agentur.de → app.vendor.com mit dem TLS-Zertifikat des Anbieters, das es abdeckt.
• Eine Theming-Schicht, die der Anbieter Ihnen zur Verfügung stellt — Logo-URL, Primärfarbe, optionale Sekundärfarbe, optionales Dark-Mode-Override, optionale benutzerdefinierte Schriftart (selten).
• E-Mail-Branding. Passwort-Reset, Einladung, Abrechnungsbelege und Benachrichtigungs-E-Mails sollten von Ihrer Domain kommen, nicht vom Anbieter. Die meisten Anbieter stoppen hier. Das Konfigurieren von SPF und DKIM für die ausgehende Mail des Anbieters unter Ihrer Domain ist operativ nicht trivial; viele Anbieter bieten „From-Name"-Branding an (der From-Header sagt „Ihre Agentur"), behalten aber die tatsächliche Sendedomain als ihre bei.
• Hilfe-Link und Support-Kontakt. Der „Hilfe"-Link im Dashboard und das In-Produkt-Chat-Widget sollten auf Ihren Support zeigen, nicht auf den des Anbieters. Überraschend oft hardcoden Anbieter ihre eigene Hilfe-URL auch bei White-Label-Plänen.

Ein häufiges Muster: Der Anbieter bietet einen „Customer Portal"-Plan an, der das Dashboard-Branding übernimmt, aber Support-Tickets mit Ihrem Account-Manager als CC an den Anbieter weiterleitet. Das funktioniert für kleine Agenturen, bricht aber zusammen, wenn der Kunde ein SLA-gebundenes Ticket einreichen möchte. Bestätigen Sie das Support-Routing im Vertrag, nicht nur auf der Marketing-Seite.

Die White-Label-Funktion in der Elido-Produktoberfläche ist unter /features/white-label dokumentiert, und die operative Anleitung finden Sie im White-Label-Guide.

Abrechnung: Der Bereich, wo Anbieter stillschweigend aufhören#

Echtes White-Label-Billing bedeutet, dass Ihr Kunde Sie bezahlt, Sie den Anbieter bezahlen, und der Anbieter für den Kunden unsichtbar ist. Es gibt drei Modelle:

Direkte Abrechnung (kein echtes White-Label). Ihr Kunde zahlt den Anbieter direkt mit dem Namen des Anbieters auf der Kreditkartenabrechnung. Sie erhalten eine Empfehlungsprovision. Das ist ein Partnerprogramm, kein White-Label, unabhängig davon, was die Preisseite nennt.

Reseller-Abrechnung mit Aufschlag. Sie kaufen Lizenzen vom Anbieter mit Rabatt, verkaufen sie zu Ihrem eigenen Preis an Ihre Kunden weiter und stellen Ihren Kunden direkt in Rechnung. Die Rechnung des Anbieters geht an Sie. Die Rechnung des Kunden kommt von Ihnen. Die Implementierung erfordert, dass Sie verfolgen, welcher Kunde welche Lizenz hat, und die Nutzung gegen die Rechnung des Anbieters abgleichen — ein manueller Prozess bei den meisten Anbietern, obwohl einige eine Nutzungsexport-API anbieten.

Vollständig mandantenfähig mit Sub-Accounts. Der Anbieter stellt ein hierarchisches Kontomodell bereit: Ihre Agentur ist das übergeordnete Konto, und jeder Ihrer Kunden ist ein Sub-Account. Sie sehen konsolidierte Nutzung; jeder Kunde sieht nur seine eigene. Die Abrechnung erfolgt auf der übergeordneten Ebene; der Anbieter sendet niemals eine Rechnung an die Sub-Accounts. Das ist, was die meisten Agenturen eigentlich wollen und was die meisten Anbieter nicht unterhalb des Enterprise-Tiers anbieten.

Das Reseller-Modell ist das häufigste bei Mid-Tier-White-Label-Plänen. Das vollständige Multi-Tenant-Modell ist am häufigsten bei Anbietern, die primär Agenturen ansprechen (weniger bei Tools, die direkt auf Unternehmen abzielen). Bestätigen Sie vor der Unterzeichnung.

Identität: Die SCIM/SSO-Frage#

Identitäts-Branding ist die Achse, die für Enterprise-Kunden am meisten und für KMU-Agenturen am wenigsten wichtig ist. Die Frage ist, ob die IT-Abteilung Ihres Kunden das Dashboard in ihren IdP (Okta, Azure AD, Google Workspace) einbinden und die Benutzerbereitstellung über SCIM verwalten kann.

Das relevante Feature-Set:

• SSO via SAML 2.0 oder OIDC. Der Kunde meldet sich beim Dashboard über seinen IdP an. Der Anbieter muss eine mandantenfähige SSO-Konfiguration unterstützen, damit jeder Kunde seinen eigenen IdP einbinden kann, ohne andere Kunden zu beeinflussen.
• SCIM 2.0-Benutzerbereitstellung. Wenn die IT-Abteilung des Kunden einen Benutzer in ihrem IdP hinzufügt, erscheint der Benutzer automatisch im Dashboard; wenn sie offboarden, wird das Dashboard-Konto deaktiviert. Das ist eine Beschaffungsanforderung für jeden Enterprise-Verkauf.
• Benutzerdefinierte Rollen und Berechtigungen. Über Admin/Editor/Viewer hinaus möchte der Kunde möglicherweise eigene Rollenzuordnungen — insbesondere für Agenturen, deren Kunden spezifische Zugriffsmuster haben. Die meisten Anbieter bieten feste Rollen unterhalb des Enterprise-Tiers an.

Für Sub-Account-Modelle wird die SSO-Konfiguration komplexer: Jeder Sub-Account benötigt seine eigene IdP-Integration. Nicht jeder Anbieter unterstützt pro-Sub-Account-SSO; einige verlangen, dass Enterprise-Kunden an der Spitze der Hierarchie statt als Sub-Accounts leben. Der SCIM und SSO Post behandelt das beschaffungsseitige Detail.

API- und Integrations-Branding#

Entwickler stellen andere Fragen zu White-Label als Marketer. Die wichtigen Fragen:

API-Endpunkt. Ruft der Entwickler des Kunden api.ihre-agentur.de oder api.vendor.com auf? Das CNAME-Eintragen der Vendor-API zu Ihrer Domain ist operativ einfach, wenn der Anbieter es unterstützt; viele tun es nicht, mit Verweis auf TLS-Zert-Komplexität. Das Ergebnis ist, dass der Entwickler die Domain des Anbieters in seiner Codebasis sieht, unabhängig davon, wie white-label das Dashboard ist.

Webhook-Signaturen. Wenn der Anbieter einen Webhook liefert, wird der Signatur-Header mit einem Schlüssel berechnet, den der Anbieter kontrolliert. Die Webhook-Quell-IP ist der POP des Anbieters. Die Signierungsschlüssel-Dokumentation liegt in den Docs des Anbieters. Webhooks transparent neu zu branden ist wirklich schwierig — es erfordert, dass der Anbieter pro-Tenant-Signierungsschlüssel und pro-Tenant-ausgehende IPs unterstützt.

SDK und Bibliotheks-Naming. Das SDK des Anbieters wird auf npm als @vendor/url-shortener veröffentlicht. Ihre Kunden npm install das. Es gibt kein transparentes Rebrand hier — selbst wenn die API white-labelled ist, ist der SDK-Paketname der des Anbieters.

Dokumentation. Die meisten Anbieter bieten ein Docs-Portal an, das Sie forken oder rebranden können. Wenige von ihnen halten die rebranded Docs automatisch mit den Vendor-Docs synchron. Sobald Sie forken, besitzen Sie die Wartung.

Die pragmatische Empfehlung: Bei der API- und Integrationsachse ist White-Label bei jedem Anbieter teilweise. Das Dashboard und die Domain können vollständig Ihres sein; die API und das SDK sind fast immer teilweise die des Anbieters. Wenn der Entwickler Ihres Kunden Ihre Docs lesen soll, planen Sie, sie zu schreiben oder zu forken.

Anbieter-Matrix: Wo die Lücken tatsächlich liegen#

Der aktuelle Stand der White-Label-Abdeckung, nach Anbieter, Stand Zugang 2026-05-22. Die vier Spalten entsprechen den oben genannten Achsen.

Anbieter	Domain	Dashboard	Abrechnung	Identität
Bitly Enterprise	Ja	Nur co-branded	Reseller-Programm	SAML SSO, kein SCIM
Rebrandly Enterprise	Ja	Benutzerdefiniertes Dashboard	Reseller mit Aufschlag	SAML SSO, kein SCIM
Short.io	Ja	Workspace-Branding	Reseller	SAML SSO bei Enterprise
Dub.co	Ja (Beta)	Benutzerdefiniertes Dashboard	Pass-through	SAML SSO
Elido	Ja	Benutzerdefinierte Domain + Theming	Sub-Accounts	SAML + SCIM

Zwei Beobachtungen aus der Matrix. Erstens ist die Dashboard-Achse der Bereich, in dem die meisten Anbieter konvergieren — co-branded oder theme-anpassbar ist der häufige Fall. Zweitens ist die Identitätsachse der Bereich, in dem Anbieter unterhalb des Enterprise-Tiers fast immer scheitern. SCIM-Bereitstellung wird häufig als „auf Anfrage verfügbar" oder „Add-on für X $/Monat pro bereitgestelltem Benutzer" angeboten. Für einen Kunden, der IT-Due-Diligence durchführt, ist SCIM ein Häkchen; für eine Agentur, die an Unternehmen weiterverkauft, schlägt das Fehlen von SCIM Deals still tot.

Operative Realität des Betriebs eines White-Labels#

Wenn Sie mit einem Anbieter unterzeichnen, der alle vier Achsen abdeckt, ist die operative Arbeit dennoch real. Die Teile, die mit dem Territorium kommen:

SLA-Weitergabe. Das SLA Ihres Kunden gegen Sie kann nicht strenger sein als Ihr SLA mit dem Anbieter. Wenn der Anbieter 99,9% mit Credits anbietet, können Sie Ihrem Kunden 99,9% mit Credits anbieten. Sie können keine 99,99% versprechen, es sei denn, Sie bauen Redundanz auf dem Anbieter auf.

Incident Response. Wenn der Anbieter einen Vorfall hat, sind Sie die kundenorientierte Oberfläche. Sie benötigen eine Statusseite, die vom Status des Anbieters abzieht (oder einen manuellen Eskalationspfad) und eine Kommunikationsvorlage für Ihre Kunden. Die meisten Anbieter zeigen Vorfälle nicht auf Ihrem White-Label-Dashboard an — die Statusseite liegt auf der Domain des Anbieters.

Feature-Parität-Drift. Der Anbieter wird Features in seinem eigenen Tempo liefern. Wenn er eine neue Funktion hinzufügt, nach der Ihr Kunde fragt, müssen Sie sie aktivieren (potenziell via Account-Flag); wenn er eine Funktion einstellt, die Ihr Kunde verwendet hat, müssen Sie den Deprecation-Zeitplan managen. Das ist der größte versteckte Kostenfaktor beim Weiterverkauf von SaaS — Sie verfolgen die Roadmap des Anbieters, als wäre sie Ihre eigene.

Compliance-Nachweis. Wenn das Beschaffungsteam Ihres Kunden Ihren SOC 2-Bericht anfordert, ist der SOC 2 des Anbieters Teil Ihres Umfangs, nicht Ihrer. Sie benötigen eine dokumentierte Sub-Processor-Beziehung und die Fähigkeit, die Compliance-Nachweise des Anbieters weiterzugeben. Der SOC 2 und HIPAA Post behandelt, wie das Evidenz-Paket aussieht.

Datenexport und Ausstieg. Wenn Sie aufhören, den Anbieter zu verwenden, müssen die Kundendaten mit Ihnen kommen. Bestätigen Sie das Exportformat und die Aufbewahrungsrichtlinie im Vertrag. „Export auf Anfrage verfügbar" ist nicht dasselbe wie „Self-Service-Export jederzeit" — und der Unterschied ist wichtig, wenn die Anbieterbeziehung endet.

Was vor der Unterzeichnung zu fragen ist#

Die Fragen, in der Reihenfolge, in der ich sie tatsächlich während der Beschaffung gestellt habe:

• Kann ich eine benutzerdefinierte Kurzdomain auf dem Plan hinzufügen, den ich angeboten bekomme, oder erfordert das den nächst höheren Tarif?
• Kann das Dashboard auf meiner Domain leben? Kann die E-Mail-„From"-Adresse meine Domain verwenden? Kann die E-Mail-Sendedomain (nicht nur der From-Header) meine Domain verwenden?
• Ist die Abrechnung direkt, Reseller oder Sub-Account? Wenn Reseller, wie hoch ist der Rabattprozentsatz und die Aufschlagsgrenze?
• Ist SSO auf meinem Plan verfügbar? SCIM-Bereitstellung? Pro-Sub-Account-SSO?
• Ist die API unter meiner benutzerdefinierten Domain adressierbar? Sind Webhook-Signierungsschlüssel pro Tenant?
• Was ist das Datenexportformat und die Aufbewahrungsrichtlinie? Kann ich auf Anfrage eine Kopie der Daten meines Kunden bekommen?
• Was ist das SLA, die Credit-Richtlinie und der Incident-Kommunikationskanal?
• Kann ich Ihren SOC 2, ISO 27001 oder anderen Compliance-Nachweis unter NDA sehen?

Wenn ein Anbieter nicht alle acht Fragen klar beantworten kann, ist der White-Label-Plan partiell. Das kann für Ihren Anwendungsfall akzeptabel sein — die meisten Agenturen und SaaS-Reseller arbeiten mit partiellem White-Label und es funktioniert gut — aber die Marketingbeschreibung sollte keine vollständige Abdeckung versprechen, wenn sie diese nicht liefert.

Weiterführende Lektüre#

• Bitly-Alternativen — die tatsächliche Feature-Lücke — der breitere Anbietervergleichs-Eckpfeiler.
• URL-Shortener für Marketer-Vergleich — die marketerseiti­ge Feature-Checkliste.
• SCIM und SSO für Marketing-Tools — der Identitätsachsen-Deep-Dive.
• SOC 2 und HIPAA für Link-Tracking — das Compliance-Pass-through-Detail.
• Branded Short Links auf Ihrer Domain einrichten — das operative Tutorial für die Domain-Achse.
• Produktoberfläche: /features/white-label und /solutions/agencies.
• Operative Anleitung: White-Label-Guide in den Docs.