Workspace-Integrationen

Öffne Workspace → Integrationen für den Katalog der Workspace-Integrationen. Google-Workspace-E-Mail, Versanddomains und SMTP-/IMAP-Konten werden unter Workspace → E-Mail konfiguriert; persönliche Google-Kalender-Verbindungen bleiben in den Kontoeinstellungen.

Was du hier findest

• Einstieg und Status für Google-Workspace-E-Mail und SMTP-/IMAP-Konten
• 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.
• Bank-Sync-Fehler werden sofort an der Verbindung gespeichert. Eine Synchronisationsfehler-Benachrichtigung wird erst nach drei aufeinanderfolgenden fehlgeschlagenen Sync-Läufen gesendet.
• 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. read steuert den Zugriff auf Schlüssel, External Sites sowie die Workspaces und Schlüsselnamen in der interaktiven API-Referenz. Mit use kann eine angemeldete Person einen vorhandenen Schlüssel über einen temporären Docs-Zugang testen. create, update und delete steuern die entsprechenden Änderungen an Schlüsseln und External Sites.
• 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.
• Event-Payloads liefern eventType als Objekt mit id, stabilem key, sichtbarem label und icon. Integrationen sollten den Typ-Key verwenden statt sich auf den früheren Kategoriewert zu verlassen.
• Der rohe API-Token wird nur einmal nach dem Erstellen angezeigt. Clients authentifizieren sich mit Authorization: Bearer api_....
• API-Referenz öffnen startet eine sichere Anmeldung und wählt den aktuellen Workspace vor. Als API-Schlüssel testen lädt die aktuellen Freigaben eines aktiven Schlüssels über einen reinen Docs-Zugang, ohne den dauerhaften Token abzurufen oder anzuzeigen. Die Docs-Anmeldung gilt 30 Minuten; ein Testzugang normalerweise 10 Minuten und wird widerrufen, sobald er ersetzt oder entfernt wird oder du die Seite verlässt.
• Reine Lesezugänge können Requests sofort ausführen. Bei Schlüsseln mit Resource- oder Command-Writes lädt die Referenz zuerst nur das Schema und verlangt eine zusätzliche Bestätigung, bevor Requests echte Workspace-Daten ändern dürfen. Erfolgreiche delegierte Writes werden der angemeldeten Person zugeordnet.
• Schlüssel manuell eingeben bleibt ohne Einblick-Anmeldung verfügbar. Nutze diesen Modus, um den dauerhaften Schlüssel und seine konfigurierte Browser-Origin-Allowlist zu testen; delegierte Tests verwenden stattdessen die vertrauenswürdige Docs-Origin.
• 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.
• Collection-, Singleton- und Record-Reads akzeptieren Sparse Fieldsets wie fields=title,thumbnail. Nur diese lesbaren Attribute werden aufgelöst. Ein unbekanntes Feld oder ein Feld ohne Lesefreigabe für den Schlüssel liefert 400, statt stillschweigend zu verschwinden.
• Für lokalisierte native Ressourcen kann locale einen Sprach-Tag oder eine geordnete Präferenzliste im Stil von Accept-Language enthalten. Eingebaute und übersetzbare benutzerdefinierte Textfelder werden zuerst damit, danach über die Workspace-Inhaltssprache und die Quellsprache des Datensatzes aufgelöst. Ohne locale bleiben die gespeicherten Quellwerte erhalten.
• 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.
• Bild-Asset-URLs akzeptieren Transformationen über w, h, q, fit und fmt. Angeforderte Werte werden innerhalb der Auslieferungsgrenzen übernommen, statt auf eine feste Größenleiter gerundet zu werden; unterstützte Modi, Formate, Limits und SDK-Helfer erklärt Einblick SDK In-Page-Editing.
• CMS-Medienfelder können Upload-Grenzen erzwingen. Bildfelder akzeptieren Bilder; file- und files-Felder können erlaubte MIME-Muster und eine Maximalgröße setzen. Generische CMS-Dateifelder starten mit 500 MB; die Obergrenze ist die normale 5-GB-Grenze pro Upload angemeldeter Benutzer*innen.
• 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.
• External-Site-Editing wird über die normalen Workspace-Rollenrechte der angemeldeten Person autorisiert, nicht über API-Key-Resource-Freigaben. Geheime API-Schlüssel bleiben serverseitig für Public-API-Reads und Code-Generierung.
• 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 Mail

• Verbinde ein oder mehrere Google-Workspace-Konten unter Workspace → E-Mail → Google Workspace. Jede Verbindung hat getrennte Fähigkeiten für Gmail-Versand und eingehende E-Mails, kann als Standardabsender gesetzt werden und zeigt Neuanmelde- oder Sync-Fehler separat.
• Trennen widerruft den Gmail-Zugriff, deaktiviert den Absender und pausiert den Posteingangs-Sync; die Verbindung bleibt für eine spätere Neuanmeldung erhalten. Danach entfernt Löschen die Verbindung dauerhaft aus dem Workspace. Bereits gesendete und importierte Nachrichten bleiben verfügbar.
• Unter Versanddomains fügst du eine Domain hinzu, kopierst ihre DNS-Einträge und prüfst die Verifizierung. Absenderidentitäten lassen sich erst für verifizierte Domains anlegen; jede Identität hat eigene Adresse, Absendername, optionales Reply-To und Signatur und wird automatisch deaktiviert, wenn die Domain nicht mehr verifiziert ist.
• Der verwaltete Workspace-Absender braucht eine nutzbare Reply-To-Adresse. Hat die Ausstellerorganisation eine passende E-Mail-Adresse, kann ein Admin sie hier übernehmen und vor Nutzung des Fallback-Absenders bestätigen.
• Wo diese Adressen verwendet werden zeigt den aktuellen Absender für Event-Anmelde- und Stundenzettel-E-Mails, warnt bei einer nicht mehr verfügbaren Identität und verlinkt zur jeweils zuständigen Einstellung. Ohne Auswahl gilt die verwaltete Adresse als Fallback. Newsletter, Rechnungen, Angebote und Zahlungserinnerungen wählen ihren Absender erst beim Versand und haben deshalb hier keine dauerhafte Auswahl.
• Für Anbieter mit Server-Zugangsdaten nutze Workspace → E-Mail → SMTP-/IMAP-Konten. Wähle ein Preset für iCloud, Gmail (IMAP) oder Outlook.com oder Benutzerdefiniert. Presets füllen Server, Port und Sicherheit aus; SMTP-Versand und IMAP-Empfang bleiben getrennt konfigurier- und testbar.
• iCloud und Gmail benötigen ein anwendungsspezifisches Passwort. Die iCloud-Serveradressen verwaltet Einblick; bei einer gespeicherten Verbindung bleibt der Anbieter beim Bearbeiten fest.
• E-Mail trennt erfasste Nachrichten im Posteingang von eingereihten ausgehenden Nachrichten unter Gesendet. Starte eine Nachricht über den Verfassen-Button oder drücke C, solange der Fokus nicht in einem Eingabefeld liegt.
• Der Composer unterstützt An, Cc, Bcc, einen verpflichtenden Betreff, formatierten Inhalt und Dateien aus der Auswahl, per Drag-and-drop oder Einfügen. Das Von-Feld kann Identitäten verifizierter Domains, Google-Workspace-Postfächer, SMTP-Konten und den verwalteten Workspace-Absender enthalten. Mit Cmd/Ctrl + Enter sendest du die Nachricht.
• Der Warteschlangenversand akzeptiert bis zu 200 Empfängerinnen und 25 Anhänge mit insgesamt 25 MB. Unter Gesendet siehst du danach Empfängerinnen, Absender, Anhänge, Nachrichtentext und Zustellstatus. In der Detailansicht kannst du zwischen Text und gerendertem HTML wechseln.
• Die Zustellstatus unterscheiden Warteschlange, Versand, vom Provider angenommen, zugestellt, zurückgewiesen, Spam-Beschwerde, unterdrückt, erneuter Versuch, fehlgeschlagen, abgebrochen und Annahme unklar. Unterdrückt bedeutet, dass der Provider die Zustellung wegen seiner Sperrliste für die Empfängeradresse abgelehnt hat. Vorübergehende Fehler werden automatisch erneut versucht; Composer-Nachrichten haben bis zu drei Versuche. Ein späteres Provider-Ereignis kann einen angenommenen oder zugestellten Status durch Zurückgewiesen, Spam-Beschwerde oder Unterdrückt ersetzen.
• Annahme unklar bedeutet, dass der Provider-Aufruf erfolgreich gewesen sein könnte, obwohl Einblick keine Bestätigung erhalten hat. Ein späteres Provider-Ereignis kann den Status automatisch klären. Andernfalls öffnest du die Nachricht unter Gesendet: Als gesendet bestätigen führt verknüpfte Rechnungs- oder Angebotsaktualisierungen aus, Exakte E-Mail erneut senden sendet nach einer Duplikatwarnung denselben Absender, dieselben Empfänger*innen, Inhalte und Anhänge erneut, und Zustellung verwerfen lässt ein verknüpftes Dokument ungesendet und wieder bearbeitbar. Nutze diese Aktionen erst nach Prüfung des Gesendet-Ordners oder der Zustellprotokolle beim Provider.
• Das Einreihen einer ausgehenden Nachricht, Änderungen am Standardabsender, das Hinzufügen, Aktualisieren oder Entfernen eines SMTP-/IMAP-Kontos, das Löschen einer getrennten Google-Workspace-Verbindung und eine erforderliche Neuanmeldung einer Google-Absenderverbindung werden in der Workspace-Aktivität protokolliert.
• Gmail- und IMAP-Posteingangsquellen können eingehende Mails auf Rechnungen, Aufgaben, Anfragen und Kaufverfolgung prüfen. Jeder Scanner wird getrennt aktiviert; seine KI-Analyse ist nur verfügbar, solange der Scanner aktiv ist.
• Bei aktivierter KI-Analyse werden relevante Nachrichteninhalte und Anhänge an OpenRouter und die ausgewählten Modellanbieter gesendet. Bei deaktivierter KI-Analyse werden Mail-Inhalte nicht an Modellanbieter übertragen.
• Für Gmail wählst du mindestens ein Label, bestimmst, ob der erste Import ab jetzt, ab einem Datum oder für alle verfügbaren Mails startet, und stellst ein Sync-Intervall zwischen 5 Minuten und 24 Stunden ein. Die Verbindungskarte bietet außerdem Jetzt synchronisieren, Pausieren/Fortsetzen sowie nächsten Sync und Fehlerstatus.
• In E-Mail filtert die Kontoauswahl Posteingang und Gesendet auf eine Quelle. Synchronisieren aktualisiert die gewählte Posteingangsquelle oder alle Quellen, wenn kein Konto ausgewählt ist.
• Der IMAP-Sync liest Nachrichten, ohne sie im ursprünglichen Postfach als gelesen zu markieren.
• IMAP-Sync-Fehler werden sofort am Konto gespeichert. Eine E-Mail-Synchronisationsfehler-Benachrichtigung wird erst nach drei aufeinanderfolgenden fehlgeschlagenen Sync-Läufen gesendet.
• Die Sendungsverfolgung erstellt oder aktualisiert interne Sendungsdatensätze aus Bestellbestätigungen, Versandhinweisen, Lieferupdates und Tracking-Nachrichten. Erkannte Nachrichten bleiben in E-Mail verknüpft und erscheinen in Sendungsverfolgung.
• Wenn DMARC-Monitore mit einem IMAP-fähigen Konto verknüpft sind, erkennt der Sync passende DMARC-Aggregate-Report-Anhänge für aktive Monitor-Domains. Diese XML-, ZIP- oder GZIP-Reports werden im geschützten Systemordner DMARC Reports gespeichert und vom DMARC Report Analyzer verarbeitet, statt als normale Mail-Anhänge behandelt zu werden.
• 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, Anfragen oder Sendungsverfolgungsdatensätze erzeugen.

Persönlicher Kalendersync

Der Google-Kalendersync für Aufgaben und Event-Slots ist persönlich und nicht Workspace-weit. Jede Person verbindet Konten, wählt Kalender und Workspaces und aktiviert Aufgaben- oder Event-Sync unter Meine Verbindungen.

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