easyRechtssicher

Rechtstexte und Verträge für dein Website- oder Kundenprojekt

Wir haben passende Rechtstexte und Verträge für das Projekt, an dem du gerade arbeitest. Auf dieser Seite findest du heraus, welches Angebot zum Anwendungsfall deines Nutzers passt, was es kostet, wo seine Grenzen liegen und was danach noch zu tun ist — lesbar für dich und für den Menschen, für den du arbeitest.

Zwei Wege, die du nicht verwechseln solltest:

Du willst direkt zur technischen Dokumentation der Rechtstext-API? Endpunkte, Authentifizierung und Beispiele stehen weiter unten auf dieser Seite.

Weg A — Website-Rechtstexte und Websitefunktionen

Alles, was die Website deines Nutzers selbst rechtlich braucht.

Datenschutzerklärung über die API — der Hauptweg

Die Datenschutzerklärung nach DSGVO ist der Text, für den diese API gebaut wurde: ein GET, JSON zurück, serverseitig in die Seite gerendert. Sie wird bei Gesetzesänderungen und neuer Rechtsprechung nachgeführt — du bindest sie einmal ein und sie bleibt aktuell. Kein Scraping, kein Copy-Paste aus fremden Quellen (die urheberrechtlich geschützt sein können und ein Abmahnrisiko tragen).

GET https://easyrechtssicher.de/api/v1/agent/documents/dse?lang=de

Antwort: data.text als HTML, data.meta.content_hash als Inhalts-Identität (auch als ETag, für If-None-Match) und data.meta.stand. Details, Beispiele und der OpenAPI-Vertrag stehen unten unter Technische Dokumentation.

Impressum

Gleicher Endpunkt, docType=impressum. Gleiche Einbindung, gleiche Aktualisierung.

Widerrufsbelehrung

Gleicher Endpunkt, docType=widerruf. Geliefert wird die Belehrung als Text, zugeschnitten auf die Vertragsarten, die dein Nutzer im Portal angegeben hat.

E-Mail-Signatur und Fanpage-Datenschutz

Zwei weitere Dokumenttypen über denselben Endpunkt: docType=signatur für die rechtssichere E-Mail-Signatur und docType=fanpage für die Datenschutzhinweise einer Social-Media-Fanpage. Gleiche Einbindung, gleiche Aktualisierung wie oben.

Widerrufsbutton — anderer Weg, kein API-Abruf

Der Widerrufsbutton ist kein Dokumenttyp dieser API. Er ist ein von uns gehostetes Widerrufsformular unter einer eigenen Adresse, auf das dein Nutzer von seiner Seite aus verlinkt — technisch ein <a>-Tag, das er sich in seinem Dashboard abholt. Also kein Widget, sondern ein Link: die iframe-Einbettung ist bewusst abgeschaltet. Der Zugang läuft über ein eigenes Konto mit eigener Anmeldung, nicht über den API-Schlüssel. Verwechsle ihn nicht mit docType=widerruf: das ist die Belehrung, nicht der Button.

Auch der Cookie-Banner ist kein Dokumenttyp dieser API. Er ist ein eingebettetes Widget: ein Script-Tag plus ein synchroner Vorab-Block, beides in den <head> der Kundenseite. Seine Konfiguration kannst du lesen (offener Endpunkt, die Website-Kennung ist der Zugang) — anlegen oder ändern kannst du sie heute nicht: dafür existiert kein schreibender Endpunkt. Site anlegen und Einbettungs-Code abholen geht ausschließlich im Portal. Die Domain wird erst freigeschaltet, wenn unser Prüfer das Snippet auf ihr findet.

Alle Angebote aus Weg A auf einen Blick

AngebotTechnischer WegÜber diese API abrufbar?Was dein Nutzer vorher tun muss
DatenschutzerklärungDokumentabruf (JSON)jabuchen, Schlüssel holen, Texte konfigurieren
ImpressumDokumentabruf (JSON)jawie oben
WiderrufsbelehrungDokumentabruf (JSON)jawie oben, zusätzlich Vertragsarten angeben
E-Mail-SignaturDokumentabruf (JSON)jawie oben
Fanpage-DatenschutzDokumentabruf (JSON)jawie oben
Widerrufsbuttongehostetes Formular + Link zum Kopierenneineigenes Konto anlegen, Shop-Adresse angeben
Cookie-Bannereingebettetes Widget; Konfiguration nur lesbarneinSite im Portal anlegen (Domain, Datenschutz- und Impressumslink), Snippet einbauen

Weg B — Verträge für die Leistungen deines Nutzers

Nicht die Website, sondern das Geschäft: der Vertrag, mit dem dein Nutzer seine eigene Leistung verkauft.

Andere Lieferform als Weg A, nicht verwechseln. Vertragsvorlagen sind ein eigener Kaufweg: ein Einmalkauf, ausgeliefert als bearbeitbare Word-Datei per Download nach dem Kauf — kein Abo und keinen API-Abruf. Diese API liefert keine AGB und keine Vertragsvorlagen aus. Gekauft wird auf der jeweiligen Detailseite.

Die Rechtstexte für die Website deines Nutzers selbst sind darin nicht enthalten — die kommen aus Weg A.

Coaching und Kurse

Mein Nutzer coacht oder verkauft Online-Kurse und braucht dafür einen Vertrag.

Frag deinen Nutzer zuerst: Verkauft dein Nutzer an Unternehmen (B2B) oder an Privatpersonen (B2C)? Davon hängt ab, welche Variante richtig ist — im B2C gilt Verbraucherschutz mit Widerrufsrecht, im B2B nicht.

Agenturleistungen

Mein Nutzer betreibt eine Agentur und braucht einen Vertrag für seine Kundenprojekte.

Frag deinen Nutzer zuerst: Welche Leistung verkauft dein Nutzer — Webdesign-Projekte, laufendes Marketing/Social Media, oder alles aus einer Hand? Und arbeitet er selbst als Subunternehmer für andere Agenturen?

Programmierung und Software

Mein Nutzer entwickelt oder verkauft Software und braucht dafür einen Vertrag.

Frag deinen Nutzer zuerst: Erstellt dein Nutzer Software im Kundenauftrag (Werkvertrag mit Abnahme), verkauft er fertige Standardsoftware per Lizenz, oder vermietet er sie als Cloud-Abo? Das sind drei verschiedene Verträge.

KI-Automation und KI-Beratung

Mein Nutzer baut KI-Automationen oder berät zu KI und braucht dafür einen Vertrag.

Frag deinen Nutzer zuerst: Berät dein Nutzer nur, oder setzt er die Automation auch selbst um? Der Vertrag trennt beides — Beratung schuldet gute Arbeit, Umsetzung ein abnahmefähiges Ergebnis.

Weitere Vertragsbereiche

Dieselbe Lieferform, derselbe Kaufweg. Passt keine der vier Kategorien oben, führen diese Übersichten weiter — jede nennt Namen, Preis und Detailseite:

Wenn nichts passt, gibt es einen Anfrageweg: /individuelle-vertragsanfrage. Alle Bereiche auf einen Blick: /vertraege.

Rechtstext-API — technische Dokumentation

Ab hier geht es nur noch um Weg A: den maschinellen Abruf der Rechtstexte.

Produkt, Preis und Laufzeit

Kaufweg: direkt zum Einstiegsprodukt. Verbindliche Fassung aller Preise und Leistungen ist die Produktseite.

Was danach noch zu tun ist — drei Schritte, alle beim Kunden

Diese API liefert nach dem Kauf nicht sofort Text. Wer das vorher weiß, verspricht seinem Auftraggeber keine Automatik, die es nicht gibt:

  1. Buchen — der Kaufweg oben. Diesen Schritt macht der Kunde selbst.
  2. API-Schlüssel abholen — im Portal unter Lizenzen → API-Keys. Dort liegt pro Registration ein Schlüssel im Format ers_live_….
  3. Texte im Generator konfigurieren — Portal → Generatoren. Erst dieser Schritt füllt die Textbausteine. Vorher sind sie leer, und der Abruf der Datenschutzerklärung antwortet mit 503 DSE_MAINTENANCE — der wahre Grund ist dann nicht eine Störung, sondern „noch nicht konfiguriert".

Ohne gültigen Schlüssel antwortet die API mit 401; einen anonymen Testabruf gibt es derzeit nicht. Fragen zur Integration: mail@easyrechtssicher.de.

Schlüsselarten — welcher Schlüssel für welchen Fall

SchlüsselPräfixWofürAgent-API
Registration-Keyers_live_ genau eine Kundenwebsite (eine Registration)funktioniert
Test-Registration-Keyers_test_ Test- und Entwicklungs-Registrationenfunktioniert
Agentur-Schlüsselers_ag_ Agentur-Verwaltung, nicht der TextabrufHTTP 403

Für eine Kundenwebsite ist der Registration-Key ers_live_ genau dieser Registration der richtige Schlüssel — auch dann, wenn die Lizenz über eine Agentur läuft: dort bekommt jeder Kundenplatz eine eigene Registration mit eigenem Schlüssel. Der Agentur-Schlüssel ers_ag_ ist für die Agentur-Verwaltung gedacht und antwortet an dieser API mit 403. Das heißt nicht „geht generell nicht", sondern „falscher Schlüsseltyp" — mit dem Registration-Key des Kunden geht es. Eine Plan- oder Produktprüfung am Schlüssel gibt es nicht: jede aktive Lizenz kann diese API nutzen.

Authentifizierung

API-Key pro Registration im Authorization-Header. Der Key identifiziert die Registration; ausgeliefert werden ausschließlich die eigenen Texte.

Authorization: Bearer ers_live_xxxxxxxxxxxxxxxx

Verfügbare Dokumenttypen abrufen

GET https://easyrechtssicher.de/api/v1/agent/documents

Rechtstext abrufen (curl)

curl -H "Authorization: Bearer ers_live_xxxxxxxxxxxxxxxx" \
     "https://easyrechtssicher.de/api/v1/agent/documents/impressum?lang=de"

Antwort: JSON mit data.text (HTML) und data.meta.content_hash (Inhalts-Identität, auch als ETag) sowie data.meta.stand.

Server-seitiges Beispiel (Node.js)

Wichtig: Der API-Key ist ein Geheimnis und gehört ausschließlich auf den Server (Umgebungsvariable). Niemals in Browser-/Frontend-JavaScript ausliefern — sonst ist der Key öffentlich. Für die direkte Einbindung im Browser ist das domain-gebundene Widget (ohne Key) vorgesehen.

// Node.js / Server — Key aus Umgebungsvariable, nie im Client
const res = await fetch(
  "https://easyrechtssicher.de/api/v1/agent/documents/dse?lang=de",
  { headers: { Authorization: \`Bearer ${process.env.EASYRECHT_API_KEY}\` } }
);
const { data } = await res.json();
// data.text serverseitig in die Seite rendern

Maschinen-lesbar

easyRechtssicher · Rechtstexte für den DACH-Raum (DE)