---
title: Backend anbinden
description: Speichern, Versionsverlauf, Kommentare, Zusammenarbeit, gespeicherte Blöcke, Medien, Test-E-Mails, Rendering und KI sind jeweils ein Konfigurationsschlüssel mit Methoden, die Sie implementieren — gegen Ihren eigenen Stack oder gegen Templatical Cloud.
---

# Backend anbinden

Der Editor bearbeitet eine Vorlage. Wo diese Vorlage gespeichert wird, wie ihre Vergangenheit aussieht, wer sie kommentiert hat, wohin ein Testversand geht, wie daraus versandfertiges HTML wird — all das liegt in Ihrem Stack, und der Editor erreicht es über ein einfaches Objekt, das Sie an `init()` übergeben.

Dieses Objekt ist ein **Provider**. Alle sind optional, und alle funktionieren gleich.

## Die Provider

```ts
import { init } from '@templatical/editor';

await init({
  container: '#editor',

  templates: myTemplateStore, // save and load
  versionHistory: myVersionStore, // past states — browse, preview, restore
  comments: myCommentStore, // threaded review, anchored per block
  collaboration: myCollaborationBackend, // live edits, presence and block locks
  savedBlocks: myBlockLibrary, // reusable groups of blocks
  media: myGallery, // images, folders, upload
  testEmail: mySender, // mail this template to a person
  render: myRenderer, // MJML and HTML output
  ai: myAiBackend, // chat attachments, rewrite, screenshot/PDF import
});
```

Die meisten Schlüssel stehen für sich; `collaboration` benötigt zusätzlich `templates`. Jede Funktion **fehlt, solange Sie ihren Schlüssel nicht übergeben**: kein `versionHistory`, kein Verlaufs-Steuerelement — keine deaktivierte Schaltfläche, kein leeres Panel, und auch der zugehörige Code wird nicht geladen.

`init({ container })` allein ist ein funktionierender Editor, der nichts persistiert.

## Provider-Schlüssel

<!-- prettier-ignore -->
| Provider | Das liefert der Editor | Das implementieren Sie |
| --- | --- | --- |
| [Speichern & Laden](/de/backend/templates) | Namensfeld direkt im Header, Speichern-Schaltfläche, Statusanzeige, `Cmd`/`Strg`+`S`, Autosave, Warnung bei ungespeicherten Änderungen | `load` · `create` · `save` |
| [Versionsverlauf](/de/backend/version-history) | Header-Steuerelement, Versionsliste, Vorschau auf der Arbeitsfläche mit eigenem Banner, Wiederherstellen mit Rückfrage | `list` · `get` · `create` · `restore` |
| [Kommentare](/de/backend/comments) | Review-Panel, Threads und Antworten, Zähler-Badges pro Block, Auflösen und Wiederöffnen | `list` · `create` · `update` · `delete` · `setResolved` |
| [Zusammenarbeit](/de/backend/collaboration) | Änderungen anderer live, eine Präsenzleiste, Block-Sperren mit Rahmen, Rückgängig, das von anderen überholte Schritte überspringt | `join` · `submit` · `operationsAfter` · und, nur gemeinsam, `acquireLock` · `renewLock` · `releaseLock` |
| [Gespeicherte Blöcke](/de/backend/saved-blocks) | Auswahlmodus auf der Arbeitsfläche, durchsuchbarer Browser mit Live-Vorschau, Einfügen an Position, Umbenennen, Löschen | `list` · `create` · `update` · `delete` |
| [Medien](/de/backend/media) | Durchsuchen an Bildfeldern, Drop-Upload, Zuschnitt, Ordner, Suche | `list` · `create` · `update` · `delete` · `folders` · `replace` · `importFromUrl` · `checkUsage` · `frequentlyUsed` · `storage` |
| [Test-E-Mails](/de/backend/test-email) | Auslöser im Header, Empfängersteuerung, Formatprüfung, exakte Vorschau, Versand- und Fehlerzustände | `send` |
| [Rendering & Export](/de/backend/render) | `toMjml()` und `toHtml()`, vorab aufgelöste Custom Blocks, aufgelöste Schriften | eines von `toMjml` · `toHtml` · `compileMjml` |
| [KI](/de/backend/ai) | ein KI-Assistent, der die Vorlage mit Rückgängig und Anhängen bearbeitet, die Verknüpfung **Aus Screenshot oder PDF importieren**, Umformulieren in der Absatz-Werkzeugleiste, statische, lokalisierte Einstiegsanfragen, KI-Kennzeichnung | aufrufbare Mitglieder: `chat` · `fixFinding` · `rewrite` · `altText` (jeweils `false \| fn`); boolesches Flag `chatAttachments`, nur wirksam, wenn `chat` eine Funktion ist; optional `conversation` |

Der Editor behält, was kleinteilig und für alle gleich ist: Änderungsverfolgung, ein verzögertes Autosave, das während Undo pausiert, eine Vorschau, die Anzeigebedingungen respektiert, die Rückfrage, bevor ein Wiederherstellen ungespeicherte Arbeit verwirft. Ihnen bleibt, wohin die Daten gehen, wer sie lesen darf und wie Ihre API aussieht.

Bei `templates`, `versionHistory`, `comments`, `savedBlocks` und `media` ist jede Mutation `false | fn`. Ein `false` erklärt die Aktion für nicht verfügbar: der Aufruf lehnt ab, und überall dort, wo der Editor ein Bedienelement dafür rendert, wird es ausgeblendet statt deaktiviert. Jede Provider-Seite behandelt ihre eigene — [gespeicherte Blöcke](/de/backend/saved-blocks#berechtigungen-steuern) und [Medien](/de/backend/media#berechtigungen-steuern) am ausführlichsten. `render` und `testEmail` sind anders geformt: Bei `render` ist jede Methode unabhängig optional, und `testEmail` besteht aus einem einzigen `send`. `collaboration` ist eine Sitzung statt eines Speichers: Es braucht `templates`, und seine drei Sperr-Methoden sind nur gemeinsam optional.

::: warning Keine Sicherheitsgrenze
Provider laufen im Browser der Nutzenden. Diese Flags formen die Oberfläche; Ihre API schützen sie nicht. Wer eine Vorlage öffnen darf, wer einen geteilten gespeicherten Block löschen darf, welche Adresse ein Test erreichen darf — setzen Sie all das zusätzlich auf Ihrem Server durch.
:::

Mit `collaboration` werden Inhaltsänderungen über `submit` persistiert; `templates.save` erhält nur Umbenennungen. Seiteneffekte für Inhaltsänderungen gehören dann in den Operations-Schreibpfad (siehe [Zusammenarbeit](/de/backend/collaboration#templates)).

## IDs

IDs kommen aus Ihrem `create()` zurück; der Editor erfindet keine. Eine Vorlagen-ID ist, was auch immer Ihr Speicher bereits verwendet — ein Datenbankschlüssel, ein Slug, eine Dokument-ID.

Diese ID ist auch der Verbindungsschlüssel. Versionsverlauf und Kommentare sind beide an eine Vorlage gebunden, ihre Bedienelemente erscheinen also erst, sobald `create()` oder `load()` eine angehängt hat.

## Fehler

Jede Provider-Methode darf ablehnen. Der Editor meldet den Fehler über `onError`, zeigt ihn dort, wohin die Nutzenden gerade schauen — Speicherstatus, geöffneter Dialog — und behält den bestätigten Zustand bei. Bereits angewendete KI-Batches bleiben bei Stop oder Fehler erhalten; Rückgängig erfordert lokale Inversen oder gespeicherten Verlauf mit `conversation.undo` (siehe [KI](/de/backend/ai#fehler)). Nichts wird als gespeichert markiert, was es nicht ist, und ein fehlgeschlagenes Löschen lässt keinen Eintrag aus der Liste verschwinden.

Mehrere dieser Meldungen landen wortgleich in der Oberfläche — schreiben Sie sie für die Person, die sie lesen wird.

## Callbacks

Zwei weitere Schnittstellen erreichen Ihr Backend, allerdings als schlichte Funktionen und nicht als Provider-Objekte — nichts zurückzuhalten, keine IDs, kein `false`:

```ts
type OnRequestMedia = (context?: MediaRequestContext) => Promise<MediaResult | null>;
type ResolvePreview = (context: PreviewResolveContext) => Promise<TemplateContent>;
```

- **`onRequestMedia`** ist eine **UI-Überschreibung** für die Medienauswahl (Bynder, Cloudinary-Widget, ein Host-Modal). Das ist nicht der Speicher — der ist der [`media`](/de/backend/media)-Provider. Sind beide gesetzt, hat der Callback Vorrang. Dokumentiert gemeinsam mit der übrigen Bildbehandlung unter [Bilder](/de/guide/images).
- **`resolvePreview`** übergibt die Vorlage an Ihr Backend und rendert, was zurückkommt, sodass eine Vorschau echte Empfängerdaten statt Merge-Tag-Labels zeigt. Nur zur Anzeige: Das Ergebnis erreicht Vorschauflächen und wird nie gespeichert, versendet oder exportiert. Siehe [Vorschau-Rendering](/de/guide/preview-rendering).

## Headless-Nutzung

`useSavedBlocks`, `useVersionHistory` und `useComments` werden aus `@templatical/core` exportiert, sodass ein Provider Ihre eigene Oberfläche versorgen kann, ganz ohne eingebundenen Editor. Der Medienzustand ist an das Modal gebunden: `useMediaLibrary` lebt in `@templatical/media-library`, und die Provider-Methoden selbst sind die Headless-API. Die jeweilige Oberfläche steht im Abschnitt *Headless-Nutzung* der einzelnen Seiten.