API Sicherheit & Authentifizierung
Hallo, ich bin Sophie! 👋 Sicherheit bei der API-Integration ist entscheidend - schließlich verarbeitest Sie sensible Geschäftsdaten. In diesem Guide erkläre ich Ihnen alle Authentifizierungsmethoden und Sicherheits-Best-Practices im Detail.
DSGVO Art. 32 & BAO §132: Alle API-Zugriffe werden protokolliert und 7 Jahre aufbewahrt. Sie sind als API-Nutzer mitverantwortlich für die sichere Handhabung Ihrer Zugangsdaten.
Übersicht der Authentifizierungsmethoden
Einfach und ideal für Server-zu-Server
API-Key AuthentifizierungKurzlebige Access Tokens mit Refresh
JWT TokensMulti-Mandanten-Zugriff
OAuth 2.0 für PartnerHTTPS, Rate Limiting, IP-Whitelist
SicherheitsmaßnahmenAPI-Key Authentifizierung
Die einfachste und häufigste Methode für Server-zu-Server-Kommunikation. Ein API-Key gehört zu Ihrem Konto und hat Zugriff auf alle Ihre Geschäftsdaten.
API-Key erstellen
Dashboard öffnen
Melde Sie bei BuchhaltGenie an und navigiere zu Einstellungen > API-Zugang > Schlüssel verwalten.
Neuen Schlüssel erstellen
Klicken Sie auf Neuen API-Schlüssel erstellen und vergib einen aussagekräftigen Namen.
Sophie’s Tipp: Verwende beschreibende Namen wie ERP-Integration-Prod oder Website-Rechnungen. So erkennst Sie später sofort, wofür welcher Schlüssel verwendet wird.
Schlüssel kopieren und sichern
Kritisch: Der Schlüssel wird nur einmal angezeigt! Kopieren Sie ihn sofort in Ihren Passwort-Manager oder Secret Store. Wenn Sie ihn verlierst, musst Sie einen neuen erstellen.
Schlüsseltypen
| Typ | Präfix | Verwendung | Umgebung |
|---|---|---|---|
| Live | sk_live_ | Produktionsumgebung | Echte Daten |
| Test | sk_test_ | Sandbox/Entwicklung | Testdaten |
Bearer Token Format
Sende den API-Key im Authorization-Header als Bearer Token:
cURL
curl -X GET "https://buchhaltgenie.at/api/v1/invoices" \
-H "Authorization: Bearer sk_live_xxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-H "Accept: application/json"Key-Rotation Best Practices
Regelmäßige Key-Rotation erhöht die Sicherheit erheblich:
| Empfehlung | Frequenz | Grund |
|---|---|---|
| Rotation | Alle 90 Tage | Minimiert Risiko bei unentdecktem Leak |
| Nach Mitarbeiteraustritt | Sofort | Zugang entziehen |
| Nach Sicherheitsvorfall | Sofort | Potenziell kompromittierte Keys invalidieren |
Neuen Key erstellen
Erstelle einen neuen API-Key bevor Sie den alten löschst.
Anwendungen aktualisieren
Aktualisiere alle Anwendungen auf den neuen Key.
Testen
Überprüfe, dass alle Integrationen mit dem neuen Key funktionieren.
Alten Key löschen
Erst wenn alles funktioniert, lösche den alten Key.
Wichtig: Lösche niemals einen Key ohne vorher einen neuen einzurichten! Sonst sind Ihre Integrationen offline.
JWT Tokens
JSON Web Tokens (JWTs) sind kurzlebige, signierte Tokens, die für zeitlich begrenzte Authentifizierung verwendet werden.
Was sind JWTs?
Ein JWT besteht aus drei Teilen, getrennt durch Punkte:
header.payload.signatureeyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJ1c2VyXzEyMzQ1IiwiYnVzaW5lc3NfaWQiOiJidXNfNjc4OTAiLCJzY29wZXMiOlsiaW52b2ljZXM6cmVhZCJdLCJleHAiOjE3MDQwNjcyMDB9.
abc123signature| Teil | Inhalt | Beschreibung |
|---|---|---|
| Header | {"alg":"HS256","typ":"JWT"} | Signatur-Algorithmus |
| Payload | User ID, Scopes, Ablaufzeit | Die eigentlichen Daten |
| Signature | HMAC-SHA256 Hash | Integritätsprüfung |
Wichtig: JWTs sind signiert, nicht verschlüsselt. Der Payload kann von jedem gelesen werden! Speichern Sie niemals sensible Daten im JWT.
Token-Lebensdauer
| Token-Typ | Lebensdauer | Verwendung |
|---|---|---|
| Access Token | 1 Stunde | API-Anfragen |
| Refresh Token | 7 Tage | Access Token erneuern |
| API-Key | Unbegrenzt | Bis zur manuellen Löschung |
Refresh-Token Flow
Wenn Ihr Access Token abläuft, kannst Sie mit dem Refresh Token einen neuen anfordern:
Flow-Diagramm
┌─────────────┐ ┌─────────────┐
│ Client │ │ API Server │
└──────┬──────┘ └──────┬──────┘
│ │
│ 1. API Request mit Access Token │
│ ─────────────────────────────────────────► │
│ │
│ 2. 401 Unauthorized (Token expired) │
│ ◄───────────────────────────────────────── │
│ │
│ 3. POST /oauth/token (Refresh Token) │
│ ─────────────────────────────────────────► │
│ │
│ 4. Neues Access Token + Refresh Token │
│ ◄───────────────────────────────────────── │
│ │
│ 5. API Request mit neuem Access Token │
│ ─────────────────────────────────────────► │
│ │
│ 6. 200 OK (Erfolg) │
│ ◄───────────────────────────────────────── │
│ │Sicherheitshinweis: Refresh Tokens müssen sicher gespeichert werden (z.B. verschlüsselt in einer Datenbank). Sie dürfen niemals im Frontend oder in Logs erscheinen!
OAuth 2.0 für Partner
OAuth 2.0 ermöglicht es Ihrer Anwendung, im Namen verschiedener BuchhaltGenie-Benutzer zu agieren - ideal für Partner-Integrationen und Multi-Mandanten-Software.
Wann OAuth 2.0 verwenden?
| Szenario | Empfehlung |
|---|---|
| Eigene Buchhaltung automatisieren | API-Key |
| SaaS-Produkt für mehrere Kunden | OAuth 2.0 |
| Partner-Integration | OAuth 2.0 |
| Mobile App | OAuth 2.0 |
| Server-zu-Server (eigene Daten) | API-Key |
Partner-Registrierung
Bevor Sie OAuth 2.0 nutzen kannst, musst Sie Ihre Anwendung registrieren:
Partner-Antrag stellen
Kontaktiere office@buchhaltgenie.at mit:
- Firmenname und UID-Nummer
- Beschreibung Ihrer Anwendung
- Geplante Scopes
- Redirect URIs
Prüfung (1-3 Werktage)
Wir prüfen Ihren Antrag und kontaktieren Sie bei Fragen.
Credentials erhalten
Sie erhalten:
client_id- Öffentliche Kennungclient_secret- Geheim halten!
Authorization Code Flow
Der sicherste OAuth 2.0 Flow für Server-seitige Anwendungen:
1. Benutzer zur Autorisierung senden
Leite den Benutzer zu unserer Autorisierungsseite:
GET https://auth.buchhaltgenie.at/oauth/authorize?
client_id=YOUR_CLIENT_ID&
redirect_uri=https://Ihre-app.at/callback&
response_type=code&
scope=invoices:read invoices:write customers:read&
state=RANDOM_STATE_STRING| Parameter | Pflicht | Beschreibung |
|---|---|---|
client_id | Ja | Ihre Client ID |
redirect_uri | Ja | Registrierte Callback-URL |
response_type | Ja | Immer code |
scope | Ja | Gewünschte Berechtigungen |
state | Ja! | CSRF-Schutz (zufälliger String) |
CSRF-Schutz: Der state Parameter ist Pflicht! Generiere einen zufälligen String, speichere ihn in der Session und prüfe ihn beim Callback.
2. Benutzer autorisiert
Der Benutzer sieht eine Übersicht der angeforderten Berechtigungen und kann zustimmen oder ablehnen.
3. Authorization Code erhalten
Nach Zustimmung wird der Benutzer zurückgeleitet:
https://Ihre-app.at/callback?
code=AUTHORIZATION_CODE&
state=RANDOM_STATE_STRING4. Code gegen Token tauschen
curl -X POST "https://auth.buchhaltgenie.at/oauth/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=authorization_code" \
-d "client_id=YOUR_CLIENT_ID" \
-d "client_secret=YOUR_CLIENT_SECRET" \
-d "code=AUTHORIZATION_CODE" \
-d "redirect_uri=https://Ihre-app.at/callback"Antwort:
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"refresh_token": "rt_xxxxxxxxxxxxxxxx",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "invoices:read invoices:write customers:read"
}5. API aufrufen
curl -X GET "https://buchhaltgenie.at/api/v1/invoices" \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."Verfügbare Scopes
| Scope | Beschreibung | Berechtigung |
|---|---|---|
invoices:read | Rechnungen lesen | Lesend |
invoices:write | Rechnungen erstellen/bearbeiten | Schreibend |
customers:read | Kundendaten lesen | Lesend |
customers:write | Kundendaten bearbeiten | Schreibend |
transactions:read | Transaktionen lesen | Lesend |
transactions:write | Transaktionen erstellen | Schreibend |
reports:read | Berichte abrufen | Lesend |
sophie:chat | Sophie AI nutzen | Interaktiv |
admin | Voller Zugriff | Alle |
Sophie’s Tipp: Fordere nur die Scopes an, die Ihre Anwendung wirklich braucht! Das erhöht das Vertrauen der Benutzer und minimiert Risiken bei einem Sicherheitsvorfall.
Redirect URIs
Redirect URIs müssen bei der Partner-Registrierung angegeben werden:
| Umgebung | Beispiel |
|---|---|
| Produktion | https://Ihre-app.at/oauth/callback |
| Staging | https://staging.Ihre-app.at/oauth/callback |
| Entwicklung | http://localhost:3000/oauth/callback |
Sicherheit: In Produktion sind nur HTTPS-URLs erlaubt! localhost ist nur für Entwicklung gestattet.
Sicherheitsmaßnahmen
HTTPS Pflicht
Alle API-Kommunikation muss über HTTPS erfolgen:
✅ https://buchhaltgenie.at/api/v1/...
❌ http://buchhaltgenie.at/api/v1/... (wird abgelehnt!)| Anforderung | Status |
|---|---|
| TLS Version | Minimum TLS 1.2, empfohlen TLS 1.3 |
| Zertifikat | Gültig, nicht abgelaufen |
| Cipher Suites | Nur moderne, sichere Suites |
| HTTP | Wird mit 301 zu HTTPS redirected |
Pflicht: API-Anfragen über HTTP werden abgelehnt. Es gibt keine Ausnahmen - auch nicht für Entwicklung oder Testing.
Rate Limiting
Um eine faire Nutzung für alle zu gewährleisten, gelten Rate Limits:
Standard-Limits nach Tarif
| Tarif | Anfragen/Minute | Anfragen/Tag | Burst-Limit |
|---|---|---|---|
| Starter | 60 | 1.000 | 10 |
| Pro | 300 | 10.000 | 50 |
| Business | 600 | 50.000 | 100 |
| Enterprise | Individuell | Individuell | Individuell |
Admin-Operationen
Für sensible Admin-Operationen gelten strengere Limits:
| Operation | Limit | Zeitfenster | Grund |
|---|---|---|---|
| Credit-Operationen | 100 | 15 Minuten | BAO §132 Compliance |
| Benutzer-Management | 100 | 15 Minuten | DSGVO Art. 32 |
| Webhook-Retry | 50 | 15 Minuten | Ressourcen-Schutz |
| Report-Generierung | 5 | 1 Stunde | Rechenintensiv |
Rate Limit Headers
Jede API-Antwort enthält Informationen über Ihr aktuelles Kontingent:
HTTP/1.1 200 OK
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 287
X-RateLimit-Reset: 1704067200Rate Limit überschritten
Bei Überschreitung erhältst Sie HTTP 429:
{
"error": {
"code": "RATE_LIMIT_EXCEEDED",
"message": "Anfragelimit überschritten. Bitte warte 32 Sekunden.",
"details": {
"retry_after": 32,
"limit": 300,
"reset_at": "2026-01-16T15:30:00Z"
}
}
}Implementiere exponentielles Backoff:
async function fetchWithRetry(url: string, options: RequestInit, maxRetries = 3): Promise<Response> {
for (let attempt = 0; attempt < maxRetries; attempt++) {
const response = await fetch(url, options);
if (response.status === 429) {
const retryAfter = parseInt(response.headers.get('Retry-After') || '1');
const waitTime = retryAfter * 1000 * Math.pow(2, attempt); // Exponentielles Backoff
console.log(`Rate limit erreicht. Warte ${waitTime}ms...`);
await new Promise(resolve => setTimeout(resolve, waitTime));
continue;
}
return response;
}
throw new Error('Max retries exceeded');
}IP-Whitelisting (Enterprise)
Enterprise-Kunden können API-Zugriffe auf bestimmte IP-Adressen beschränken:
Einstellungen öffnen
Navigiere zu Einstellungen > API-Zugang > Sicherheit.
IP-Whitelist aktivieren
Aktiviere IP-Whitelist und füge Ihre Server-IPs hinzu.
IPs konfigurieren
{
"ip_whitelist": [
"203.0.113.10", // Einzelne IP
"203.0.113.0/24", // IP-Range (CIDR)
"2001:db8::1" // IPv6
]
}Sophie’s Tipp: IP-Whitelisting ist ideal für feste Server-Standorte. Bei dynamischen IPs (z.B. Cloud-Funktionen) ist es oft nicht praktikabel - setze dann besonders auf sichere Key-Aufbewahrung.
CORS Konfiguration
Cross-Origin Resource Sharing (CORS) ist für Browser-basierte Anwendungen relevant:
| Origin | Erlaubt | Hinweis |
|---|---|---|
| Registrierte Domains | ✅ | Bei Partner-Registrierung angeben |
localhost:* | ✅ | Nur für Entwicklung |
*.buchhaltgenie.at | ✅ | Eigene Domains |
| Unbekannte Origins | ❌ | Wird blockiert |
CORS-Header in der Antwort:
Access-Control-Allow-Origin: https://Ihre-app.at
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type, Accept
Access-Control-Max-Age: 86400Wichtig: Für Server-zu-Server-Kommunikation ist CORS nicht relevant - es betrifft nur Browser! Ihre Backend-Anwendung kann ohne CORS-Einschränkungen auf die API zugreifen.
Fehlerbehandlung
HTTP-Statuscodes
| Code | Bedeutung | Beschreibung | Aktion |
|---|---|---|---|
401 | Unauthorized | API-Key ungültig/fehlt | Key prüfen, neu authentifizieren |
403 | Forbidden | Keine Berechtigung | Scope prüfen, Admin kontaktieren |
429 | Too Many Requests | Rate Limit überschritten | Warten, Backoff implementieren |
401 Unauthorized
{
"error": {
"code": "UNAUTHORIZED",
"message": "Ungültiger oder fehlender API-Schlüssel.",
"details": {
"hint": "Prüfe den Authorization-Header (Bearer Token Format)"
}
}
}Häufige Ursachen:
- API-Key fehlt oder ist falsch formatiert
- API-Key wurde gelöscht oder deaktiviert
- Access Token ist abgelaufen (bei OAuth)
// Fehlerbehandlung
const response = await fetch('/api/v1/invoices', {
headers: { 'Authorization': `Bearer ${apiKey}` }
});
if (response.status === 401) {
// Bei OAuth: Token erneuern
if (isOAuthToken) {
await refreshAccessToken();
// Anfrage wiederholen
} else {
// Bei API-Key: Key prüfen
console.error('API-Key ungültig - bitte in den Einstellungen prüfen');
}
}403 Forbidden
{
"error": {
"code": "FORBIDDEN",
"message": "Sie haben keine Berechtigung für diese Aktion.",
"details": {
"required_scope": "invoices:write",
"your_scopes": ["invoices:read"]
}
}
}Häufige Ursachen:
- Fehlender Scope bei OAuth
- Zugriff auf fremde Ressourcen
- Feature nicht im Tarif enthalten
429 Too Many Requests
{
"error": {
"code": "RATE_LIMIT_EXCEEDED",
"message": "Zu viele Anfragen. Bitte warte 32 Sekunden.",
"details": {
"retry_after": 32,
"limit": 300,
"window": "minute"
}
}
}Best Practice: Exponentielles Backoff
async function apiCall(url: string, options: RequestInit): Promise<Response> {
const maxRetries = 5;
let lastError: Error | null = null;
for (let i = 0; i < maxRetries; i++) {
try {
const response = await fetch(url, options);
if (response.status === 429) {
const retryAfter = parseInt(response.headers.get('Retry-After') || '1');
const delay = retryAfter * 1000 * Math.pow(2, i); // Exponentiell
console.warn(`Rate limit, warte ${delay}ms (Versuch ${i + 1}/${maxRetries})`);
await sleep(delay);
continue;
}
return response;
} catch (error) {
lastError = error as Error;
}
}
throw lastError || new Error('Max retries exceeded');
}DSGVO & BAO Compliance
Audit Logging (BAO §132)
Alle API-Zugriffe werden 7 Jahre protokolliert:
| Protokolliertes Feld | Beispiel | Rechtsgrundlage |
|---|---|---|
| Zeitstempel | 2026-01-16T10:30:00Z | BAO §132 |
| User ID | user_12345 | BAO §132 |
| IP-Adresse | 203.0.113.10 | DSGVO Art. 32 |
| Endpoint | POST /api/v1/invoices | BAO §132 |
| Aktion | CREATE | BAO §132 |
| Ressource | invoice_67890 | BAO §132 |
| Status | SUCCESS / FAILED | BAO §132 |
BAO §132 Anforderung: Alle buchhalterisch relevanten Vorgänge müssen nachvollziehbar sein. Die Audit-Logs können bei einer Betriebsprüfung angefordert werden.
Datenminimierung (DSGVO Art. 5)
Best Practices für API-Nutzung:
| Prinzip | Umsetzung |
|---|---|
| Nur notwendige Daten | Fordere nur benötigte Felder an (?fields=id,name,email) |
| Minimale Scopes | Nur Scopes anfordern, die wirklich gebraucht werden |
| Keine Logs mit PII | Logge keine personenbezogenen Daten in Ihre Systeme |
| Zeitliche Begrenzung | Lösche lokale Kopien nach Gebrauch |
// ✅ Gut: Nur benötigte Felder
const response = await fetch('/api/v1/customers?fields=id,company_name');
// ❌ Schlecht: Alle Daten abrufen
const response = await fetch('/api/v1/customers'); // Enthält alle FelderVerschlüsselung
| Ebene | Standard | Beschreibung |
|---|---|---|
| Transport (in transit) | TLS 1.3 | Alle API-Verbindungen verschlüsselt |
| Speicherung (at rest) | AES-256 | Datenbank und Backups verschlüsselt |
| Schlüsselverwaltung | HSM | Hardware Security Module für Keys |
Compliance-Checkliste für API-Nutzer
Als API-Nutzer bist Sie mitverantwortlich:
- API-Keys sicher gespeichert (nicht im Code!)
- HTTPS für alle Verbindungen verwendet
- Minimale Scopes angefordert (Least Privilege)
- Lokale Datenkopien nur bei Bedarf
- Auftragsverarbeitungsvertrag (AVV) abgeschlossen
- Zugriffsberechtigungen dokumentiert
- Incident-Response-Plan vorhanden
AVV Pflicht: Wenn Sie über die API personenbezogene Daten verarbeitest, ist ein Auftragsverarbeitungsvertrag gemäß DSGVO Art. 28 Pflicht. Kontaktiere office@buchhaltgenie.at für den AVV.
API-Schlüssel sicher aufbewahren
// Umgebungsvariable
const apiKey = process.env.BUCHHALTGENIE_API_KEY;
// Secret Manager (AWS, Azure, GCP)
const apiKey = await secretManager.getSecret('buchhaltgenie-api-key');
// Nur relevante Daten loggen
console.log('Invoice created:', invoice.id);// NIEMALS im Code!
const apiKey = "sk_live_abc123";
// NIEMALS in Git!
// .env Datei nicht committen!
// NIEMALS loggen!
console.log('API Key:', apiKey);Empfohlene Tools
| Tool | Verwendung | Eignung |
|---|---|---|
| AWS Secrets Manager | Cloud-Anwendungen | Enterprise |
| Azure Key Vault | Azure-Umgebungen | Enterprise |
| HashiCorp Vault | On-Premise | Alle |
| 1Password / Bitwarden | Teams | Kleine Teams |
| Umgebungsvariablen | Einfache Setups | Entwicklung |
Webhook-Signaturen verifizieren
Wenn Sie Webhooks nutzt, verifiziere immer die Signatur:
TypeScript
import crypto from 'crypto';
function verifyWebhookSignature(
payload: string,
signature: string,
secret: string
): boolean {
const expectedSignature = crypto
.createHmac('sha256', secret)
.update(payload)
.digest('hex');
// Timing-sicherer Vergleich!
return crypto.timingSafeEqual(
Buffer.from(signature),
Buffer.from(`sha256=${expectedSignature}`)
);
}
// Express.js Beispiel
app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
const signature = req.headers['x-buchhaltgenie-signature'] as string;
const payload = req.body.toString();
if (!verifyWebhookSignature(payload, signature, process.env.WEBHOOK_SECRET!)) {
console.error('Ungültige Webhook-Signatur');
return res.status(401).send('Unauthorized');
}
const event = JSON.parse(payload);
// Event sicher verarbeiten...
res.status(200).send('OK');
});Kritisch: Verwende immer timingSafeEqual oder hash_equals für den Signaturvergleich! Ein normaler === Vergleich ist anfällig für Timing-Angriffe.
Sicherheitsvorfälle melden
Wenn Sie eine Sicherheitslücke entdeckst:
| Kontakt | Details |
|---|---|
| office@buchhaltgenie.at | |
| PGP-Key | Verfügbar auf buchhaltgenie.at/security |
| Reaktionszeit | Innerhalb von 24 Stunden (werktags) |
Bug Bounty: Für schwerwiegende Sicherheitslücken bieten wir eine angemessene Belohnung. Details finden Sie in unserer Security Policy.
Bei Kompromittierung Ihrer API-Keys:
Sofort handeln
Lösche den kompromittierten Key sofort in den BuchhaltGenie-Einstellungen.
Audit-Logs prüfen
Prüfe in Einstellungen > API-Zugang > Zugriffsprotokolle auf verdächtige Aktivitäten.
Support informieren
Kontaktiere office@buchhaltgenie.at mit Details zum Vorfall.
Neuen Key erstellen
Erstelle einen neuen Key und aktualisiere Ihre Anwendungen.
Häufige Fragen
Wie lange sind API-Keys gültig?
API-Keys laufen nicht automatisch ab. Sie bleiben gültig, bis Sie sie manuell löschst. Wir empfehlen jedoch eine Rotation alle 90 Tage.
Kann ich mehrere API-Keys haben?
Ja! Wir empfehlen separate Keys für verschiedene Anwendungen und Umgebungen. So kannst Sie bei Bedarf einzelne Zugänge widerrufen.
Was passiert bei einem Sicherheitsvorfall?
Gemäß DSGVO Art. 33/34 informieren wir Sie innerhalb von 72 Stunden. Wir haben einen dokumentierten Incident-Response-Plan.
Werden API-Zugriffe protokolliert?
Ja, alle Zugriffe werden gemäß BAO §132 für 7 Jahre protokolliert. Dies dient der Nachvollziehbarkeit bei Betriebsprüfungen.
Wo werden meine Daten gespeichert?
Alle Daten werden in ISO 27001-zertifizierten Rechenzentren in Frankfurt, Deutschland gespeichert. Es findet keine Datenübertragung außerhalb der EU statt.
Nächste Schritte
- Authentifizierung - Grundlagen der API-Authentifizierung
- Rate Limits - Detaillierte Limit-Informationen
- Webhooks - Event-basierte Integrationen
- API Endpunkte - Mit der Integration starten
Hinweis: Diese Dokumentation dient als technische Übersicht. Für rechtliche Fragen zur DSGVO-Compliance oder Auftragsverarbeitung konsultiere bitte einen Datenschutzbeauftragten oder kontaktiere office@buchhaltgenie.at.