Administration

Workspace-Integrationen

Verwalte workspace-weite Integrationen wie E-Mail-Verbindungen, Mail-Automatisierung, Bankkonten, Public API, Zahlungsanbieter und GitHub.

Workspace-Integrationen

Öffne Workspace → Integrationen, um Integrationen zu verwalten, die zum Workspace gehören. Die E-Mail-Einrichtung liegt auf dieser Seite, nicht in den persönlichen Kontoeinstellungen.

Was du hier findest

  • Gemeinsame OAuth- und E-Mail-Verbindungen für SMTP-Versand und IMAP-Sync
  • Bankkonto-Integrationen mit Consent-Status und Erneuerung
  • Public API und API-Schlüssel
  • Zahlungsanbieter-Integrationen
  • GitHub-Integration

Bankkonten

  • Verbundene Bankkonten zeigen Provider-Status, verknüpfte Konten, letzte Synchronisierung, Consent-Ablauf und gespeicherte Provider-Fehler.
  • Verbindungen, deren Consent abgelaufen ist oder innerhalb von sieben Tagen abläuft, zählen auf dem Integrationen-Tab und zeigen einen Hinweis auf der Bankverbindung.
  • Mit Consent erneuern autorisierst du eine bestehende Verbindung neu, ohne importierte Transaktionen oder Zuordnungen zu verlieren.
  • Wenn ein Anbieter geänderte Konto-IDs liefert, verwendet Einblick passende Kontodatensätze nach IBAN weiter, soweit möglich. Konten, die der Anbieter nicht mehr zurückgibt, werden inaktiv gesetzt statt gelöscht.
  • Manuelle Bankkonten aus Banktransaktionen erscheinen als Manual import-Verbindungen. Sie verwenden keine Consent-Erneuerung und werden beim Provider-Sync übersprungen.
  • Ausstehende, fehlerhafte, abgelaufene und bald ablaufende Verbindungen können auf derselben Karte erneut versucht werden. Widerrufene Verbindungen können gelöscht werden.

Public API

  • Öffne Workspace → API, wenn das API-Feature für den Workspace aktiviert ist.
  • API-Einstellungen folgen der Rollenberechtigung api. Rollenrechte für Lesen, Erstellen, Aktualisieren und Löschen steuern das Anzeigen von Schlüsseln und External Sites, deren Anlage, Änderungen an API-Schlüssel-Freigaben oder Origins sowie Widerruf oder Entfernen.
  • Bei Resource-Reads greifen API-Schlüssel nur auf die ausgewählten CMS-Collections und unterstützten nativen Endpunkte zu. Die aktuellen nativen Collection-Endpunkte sind buildings, events, festivals, jobs und products.
  • Pro Endpunkt legst du lesbare Felder und optionale serverseitige Filter fest. Felder können nur für Filter verfügbar bleiben, ohne im Payload zurückgegeben zu werden.
  • Für Standard-Resource-Writes vergibst du create, update und delete pro Ressource. CMS-Ressourcen unterstützen alle drei Aktionen. Native Resource-Writes unterstützen aktuell buildings, events und festivals; jobs und products sind über die Standard-Resource-API nur lesbar.
  • Create- und Update-Requests akzeptieren nur Felder, die für diese Ressource als schreibbar ausgewählt sind. CMS-Writes nutzen /api/v1/cms/{slug}, native Writes nutzen /api/v1/{slug}; Updates und Deletes ergänzen den Record-Identifier im Pfad. Native Deletes archivieren Gebäude, Event oder Festival; CMS-Deletes entfernen den CMS-Record.
  • Wenn ein Admin ein lesbares Feld zu einer CMS-Collection hinzufügt, kann Einblick anbieten, dieses Feld aktiven API-Schlüsseln hinzuzufügen, die diese Collection bereits lesen. Widerrufene oder abgelaufene Schlüssel und Schlüssel ohne passende Collection-Freigabe werden übersprungen.
  • Ressourcen mit status-Feld nutzen standardmäßig status = published; Jobs und Events nutzen zusätzlich visibility = public. Wenn ein Schlüssel andere Statuswerte oder Sichtbarkeiten ausgeben soll, hinterlege dafür einen expliziten Filter.
  • Event-Ressourcen enthalten Event-Metadaten sowie berechnete Felder start, end, allDay, Relations-Zusammenfassungen, Titelbilddaten und Slot-Daten aus den Event-Slots.
  • Der rohe API-Token wird nur einmal nach dem Erstellen angezeigt. Clients authentifizieren sich mit Authorization: Bearer api_....
  • Jeder API-Schlüssel kann Browser-Zugriffe optional auf bestimmte Origins begrenzen. Anfragen aus anderen Browser-Origins scheitern dann per CORS, serverseitige Aufrufe ohne Origin-Header funktionieren weiter.
  • Public Commands sind von Resource-Writes getrennt. Freigegebene Commands sind unter /api/v1/commands/{name} aufrufbar, unter /api/v1/commands/schema auffindbar und umfassen aktuell öffentliche Job-Bewerbungsbefehle, Newsletter-Anmeldungen sowie vertrauenswürdige externe Sync-Befehle.
  • Resource-Writes und Public Commands akzeptieren optional den Header Idempotency-Key mit bis zu 200 Zeichen. Wird derselbe Key für dieselbe Route und denselben Payload erneut genutzt, kommt das gespeicherte Ergebnis zurück; bei anderem Payload gibt es einen Konflikt.
  • Die Seite verlinkt auf das schlüsselspezifische Schema unter /api/v1/schema, /api/v1/openapi und /api/v1/openapi.json und zeigt Installationsbefehle für @einblick/sdk. Das OpenAPI-Dokument enthält getrennte Writable-Attribute-Schemas für Create- und Update-Requests, sodass Updates nur die geänderten Felder brauchen.
  • Collection-Endpunkte unterstützen limit, cursor und sort. Nutze komma-separierte Feldnamen und stelle für absteigende Sortierung ein - voran. Ohne explizites sort folgen CMS-Collections der in Einblick gespeicherten manuellen Reihenfolge, und jeder Record liefert diesen Wert als sort in den Record-Metadaten mit.
  • Lesbare CMS-Relationsfelder lassen sich per include erweitern. Verknüpfte Records erscheinen dann in included und funktionieren nur, wenn derselbe Schlüssel auch Zugriff auf die Ziel-Collection hat.
  • CMS-richtext-Felder kommen als strukturierte Dokument-JSON zurück. Asset-Payloads enthalten stabile URLs, optionale width-, height-, title-, copyright-, description-, tags- und sort-Werte für geordnete Mehrfachdateien. Wenn zu einem CMS-Video eine Web-Playback-Variante erzeugt wurde, liefert die öffentliche Asset-URL diese browser-kompatible MP4- oder WebM-Datei statt des Originaluploads aus.
  • Browser-Anfragen an nicht transformierte Asset-URLs werden mit CORS-Headern und Range-Support geproxyt. Serverseitige Aufrufe ohne Origin-Header können stattdessen kurzlebigen Storage-Redirects folgen.
  • Auf derselben Seite verwaltest du auch External Sites für Live-In-Page-Editing. Jede Site speichert erlaubte Origins, den publishable site key und optional einen relativen Revalidierungspfad für Host-Caches.
  • Wenn Revalidierung eingerichtet ist, sendet Einblick nach CMS-Inhaltsänderungen einen POST an den Revalidierungspfad auf jeder erlaubten Origin. Standard ist /api/einblick/revalidate; ein optionales Shared Secret wird als x-einblick-revalidate-secret gesendet.
  • Siehe Einblick SDK In-Page-Editing für Framework-Support und Hinweise zur Revalidierung von Host-Caches.

Zahlungsanbieter

  • Stripe-Zahlungsverbindungen werden im Zahlungsanbieter-Bereich dieser Seite verwaltet. Ein verbundenes Stripe-Konto kann Zahlungen und Rückerstattungen annehmen, wenn Stripe diese Fähigkeiten meldet.
  • Verbundene Stripe-Konten werden außerdem vom stündlichen Accounting-Sync verarbeitet. Einblick importiert Stripe-Balance-Transaktionen und Payouts, verknüpft nach Möglichkeit Payment-Session-Referenzen und erzeugt Journalbuchungen über Stripe-Verrechnung und Zahlungsanbieter-Gebührenkonten.
  • Der erste Accounting-Sync blickt bis zu 90 Tage zurück. Spätere Läufe überlappen den letzten erfolgreichen Sync um zwei Tage, damit nachträgliche Stripe-Updates aktualisiert werden können.

E-Mail-Konten und eingehende Mails

  • Für Google Workspace oder Microsoft 365 nutze Workspace → Integrationen → Verbundene Dienste.
  • Für Anbieter mit Server-Zugangsdaten nutze Workspace → Integrationen → SMTP/IMAP-Zugangsdaten. Die SMTP- und IMAP-Bereiche können die eingegebenen Zugangsdaten testen und Erfolg oder Fehler direkt im Formular anzeigen, bevor du speicherst.
  • Gemeinsame Postfächer können eingehende Mails auf Rechnungen, Aufgaben und Anfragen prüfen.
  • Für unterstützte Mail-Automationen gibt es optionale KI, unter anderem für Aufgaben- und Anfragenanalyse.
  • Eingehende Mails werden stündlich synchronisiert.
  • Der IMAP-Sync liest Nachrichten, ohne sie im ursprünglichen Postfach als gelesen zu markieren.
  • Jede erfasste Nachricht bleibt in E-Mail sichtbar. Dort können Teammitglieder Anhänge, Nachrichtentext und erzeugte Datensätze prüfen.
  • Mail lädt längere Postfächer beim Scrollen nach und sucht in Betreff, Absenderin, Empfängerinnen und Vorschautext. Du kannst nach Postfach filtern; im Posteingang gibt es zusätzlich einen Filter für Nachrichten mit Anhängen.
  • Automatisch erzeugte Anfragen brauchen Workspace-Defaults für ausstellende Organisation und Währung. Fehlen diese, bleibt die E-Mail sichtbar, aber die Anfrage wird nicht angelegt.
  • Einblick-Systemmails von @einblick.xyz werden vom Eingangserkenner unterdrückt, damit automatische Benachrichtigungen keine neuen Rechnungen, Aufgaben oder Anfragen erzeugen.

Warum Events davon abhängen

Event-Slots können in externe Kalender synchronisiert werden, aber workspace-weite Provider und der Verbindungsumfang werden hier konfiguriert. Die persönliche Konto- und Geräte-Verknüpfung liegt weiterhin in Meine Verbindungen.

Verwandte Doku: Events, Jobs, Meine Verbindungen, Workspace-Einstellungen