# Anbindungen

Unter Anbindungen hinterlegst du Zugänge zu Sentry, Firebase, DNS-Anbietern, zum E-Mail-Versand und zu KI-Providern einmal für deine ganze Organisation.

> Source: https://www.mainpath.ai/de/docs/connections/

Unter **Anbindungen** hinterlegen Administratoren Zugänge zu externen Diensten einmal für die ganze Organisation; in den Projekten wählst du sie aus einer Liste aus.

Über **Anbindung hinzufügen** wählst du die Kachel des Dienstes. Die Auswahl ist nach Kategorien gruppiert (DNS, E-Mail, Push-Benachrichtigungen, Fehler-Tracking, Git, Monitoring, KI-Provider); dieselbe Gliederung gilt für bereits hinterlegte Zugänge, sodass mehrere Accounts einer Kategorie nebeneinander stehen. Name und Slug dienen der Anzeige in den Projekten, die Zugangsdaten prüft MainPath bei mehreren Diensten direkt.

## Fehler erfassen mit Sentry

Du verbindest dein Sentry-Konto per **Mit Sentry verbinden** für sentry.io oder mit einem API-Token, der auch selbst gehostete Instanzen abdeckt. Aktivierst du Sentry bei einer Komponente unter **Funktionen**, legt MainPath das Projekt in deinem Konto an und schreibt die DSN in die Konfiguration. Den Token beschreibt [Sentry: Zugangsdaten]({{< relref "sentry-credentials" >}}), den Überblick [Error-Tracking]({{< relref "error-tracking" >}}).

## Push-Benachrichtigungen mit Firebase

**Google / Firebase** dient Push-Benachrichtigungen für Apps; empfohlen ist ein Service-Account-JSON, während **Mit Firebase verbinden** per OAuth noch das Badge **Beta** trägt. An der App aktivierst du Firebase unter **Funktionen** und wählst den Zugang aus. Beide Wege beschreibt [Firebase: Zugangsdaten]({{< relref "firebase-credentials" >}}).

## Git-Hosting mit GitHub oder GitLab

Unter **Git** verbindest du ein GitHub- oder GitLab-Konto, wenn Anwendungs-Repositories nicht in der GitLab-Instanz von MainPath liegen sollen. Beim Projekt wählst du ganz unten **Automatisch generiert (empfohlen)**, **GitHub** oder **GitLab**. OAuth ist der bevorzugte Weg; sonst ein API-Token. Einrichtung: [GitHub: Zugangsdaten]({{< relref "github-credentials" >}}) und [GitLab: Zugangsdaten]({{< relref "gitlab-credentials" >}}).

## KI-Provider

Unter **KI-Provider** hinterlegst du API-Keys für OpenAI, Anthropic, Google Gemini, Mistral AI und Cursor. OAuth für den API-Zugang bieten diese Anbieter nicht an. Beim Anlegen eines Workspaces wählst du die Zugänge aus — mehrere verschiedene Anbieter, aber nur einen Account pro Anbieter. Regeln und Skills werden immer installiert; der KI-Agent wird mit den Keys vorkonfiguriert und gestartet.

- [OpenAI: Zugangsdaten]({{< relref "openai-credentials" >}})
- [Anthropic: Zugangsdaten]({{< relref "anthropic-credentials" >}})
- [Google Gemini: Zugangsdaten]({{< relref "google-gemini-credentials" >}})
- [Mistral AI: Zugangsdaten]({{< relref "mistral-credentials" >}})
- [Cursor: Zugangsdaten]({{< relref "cursor-credentials" >}})

## Eigener Beszel-Hub

Unter **Monitoring** hinterlegst du optional einen eigenen Beszel-Hub. Server nutzen standardmäßig den von MainPath verwalteten Dienst; am Server kannst du deinen Hub auswählen. Details: [Beszel: eigener Hub]({{< relref "beszel-credentials" >}}).

## DNS-Einträge über Cloudflare, IONOS, united-domains, GoDaddy, Hetzner, Hostinger, DigitalOcean oder Gandi

Unter **DNS** verbindest du die Zone, in der deine Domain wirklich liegt. MainPath schreibt dann A- und CNAME-Einträge selbst, sobald ein Projekt Domains und eine Server-Adresse hat. In den Details jeder DNS-Anbindung kannst du zusätzlich Domains für SSL per DNS-01 anhaken, falls der Server nicht öffentlich erreichbar ist.

- **Cloudflare**: API-Token, DNS-only ohne Proxy, damit Let's Encrypt den Server erreicht. [DNS mit Cloudflare setzen]({{< relref "dns-cloudflare" >}}).
- **IONOS**: API-Key aus dem **Hosting-Developer-Hub** (nicht IONOS Cloud). [DNS mit IONOS setzen]({{< relref "dns-ionos" >}}).
- **united-domains**: API-Key der DNS-API im Format `prefix.secret`. [DNS mit united-domains setzen]({{< relref "dns-united-domains" >}}).
- **GoDaddy**: Personal Access Token oder klassisches Key/Secret. [DNS mit GoDaddy setzen]({{< relref "dns-godaddy" >}}).
- **Hetzner DNS**: Cloud-API-Token mit Read & Write für das Console-Projekt mit den Zonen. Getrennt von der Server-Anbindung. [DNS mit Hetzner setzen]({{< relref "dns-hetzner" >}}).
- **Hostinger DNS**: API-Token mit DNS-Rechten. Getrennt von der Hostinger-Server-Anbindung. [DNS mit Hostinger setzen]({{< relref "dns-hostinger" >}}).
- **DigitalOcean**: Personal Access Token mit Lese- und Schreibrechten für Domains. [DNS mit DigitalOcean setzen]({{< relref "dns-digitalocean" >}}).
- **Gandi**: Personal Access Token mit LiveDNS. [DNS mit Gandi setzen]({{< relref "dns-gandi" >}}).

## E-Mail-Versand

**Mailtrap**, **Resend** und **SendGrid** brauchen jeweils nur ein API-Token und zeigen Status und Sending Domains samt DNS-Prüfung an; **E-Mail (SMTP)** nimmt einen generischen Zugang für jeden anderen Anbieter. Alle erscheinen in den Projekten unter **Mail-Account**. Die Einrichtung beschreiben [SMTP mit Mailtrap]({{< relref "smtp-mailtrap-setup" >}}), [SMTP mit Resend]({{< relref "smtp-resend-setup" >}}) und [SMTP mit SendGrid]({{< relref "smtp-sendgrid-setup" >}}), die Unterschiede [E-Mail-Versand]({{< relref "email-delivery" >}}).

## Was nicht unter Anbindungen liegt

Die Zugänge zu App Store, Play Store und Microsoft Store liegen unter **Store-Accounts** und werden an der App ausgewählt, wie [Store-Accounts]({{< relref "store-accounts" >}}) beschreibt. SSH-Zugänge und die API-Token für Hetzner und Hostinger liegen unter **Server** hinter **Zugangsdaten verwalten**; den Ablauf zeigt [Cloud-Server]({{< relref "cloud-servers" >}}). Kubernetes-Cluster und Cloud-Konten liegen unter [Kubernetes Cluster]({{< relref "kubernetes-integration" >}}) und [Cloud-Accounts]({{< relref "cloud-accounts" >}}).