Muss man programmieren können, um Xano zu verwenden?

Nein. Xanos visueller Function Stack erlaubt es dir, komplexe Geschäftslogik ohne Code zu bauen. Du verkettest Schritte für Datenbankabfragen, externe API-Aufrufe, Bedingungen und Datentransformationen in einer drag-and-drop Oberfläche. Für sehr komplexe Berechnungen gibt es einen Code-Schritt, aber die meisten SaaS-Backend-Anforderungen werden vollständig ohne Code abgedeckt.

Wie integriert man Xano mit deutschen Buchhaltungsdiensten wie DATEV?

Xanos External API Request-Schritt verbindet sich mit jedem REST-API. DATEV, Lexoffice und sevDesk haben alle REST-APIs, die Xano direkt verarbeitet. Für Stripe-Zahlungen in EUR und automatisches Umsatzsteuer-Handling unterstützt Stripe die deutschen Mehrwertsteuer-Anforderungen. Wir haben diese Integrationen für deutsche SaaS-Kunden ohne eine einzige Zeile benutzerdefinierten Servercode gebaut.

Kann Xano DSGVO-Anforderungen zur Datenspeicherung erfüllen?

Xano bietet EU-Regionauswahl für die Datenspeicherung, was eine grundlegende Anforderung für DSGVO- und Schrems-II-Konformität ist. Deine Daten bleiben innerhalb der EU. Für zusätzliche Kontrolle kannst du Xano als API-Layer mit Supabase als Datenbank kombinieren, Supabase bietet noch feinere Kontrolle mit RLS und explizitem EU-Hosting in Frankfurt.

Was passiert mit meinem Xano-Backend, wenn ich zu Custom Code wechseln möchte?

Xano exponiert Standard-REST-Endpoints mit wohldefinierten JSON-Antworten. Dein WeWeb-Frontend oder FlutterFlow-App kommuniziert über diese Endpoints genauso wie mit einem handgeschriebenen Backend. Wenn du Xano eines Tages durch ein Custom Backend ersetzen möchtest, behältst du dein Frontend unverändert und tauschst nur die API dahinter aus, ohne Kundenauswirkung.

Xano REST API Guide: Backend ohne Code aufbauen

Das Datenmodell aufsetzen

Beginne mit deinem Datenbankschema, bevor du Endpoints aufbaust. Xanos visueller Tabellen-Builder unterstützt alle PostgreSQL-Datentypen: Text, Integer, Boolean, JSON, Timestamps und Dateireferenzen.

Schlüsselkonventionen, die wir verwenden: Jede Tabelle bekommt einen created_at und updated_at Timestamp (Xano fügt diese automatisch hinzu), verwende Integer-IDs für Performance und JSON-Felder sparsam, normalisiere, wo möglich.

Für Multi-Tenant-SaaS sollte jede Tabelle einen user_id oder workspace_id Fremdschlüssel haben. Das hält deine Zugriffskontroll-Logik sauber und konsistent. In einer typischen deutschen B2B-SaaS, sagen wir ein HR-System oder ein Beschaffungstool, bedeutet das, dass jede Organisation (Kunde) ihren isolierten Datensatz hat, ein fundamentales DSGVO-Anforderung.

API-Endpoints strukturieren

Xano generiert automatisch CRUD-Endpoints für jede Tabelle. Für Produktions-Apps willst du aber benutzerdefinierte Endpoints, die Geschäftslogik verarbeiten.

Unsere Namenskonvention: GET /api/[ressource] (Liste), GET /api/[ressource]/:id (Detail), POST /api/[ressource] (Erstellen), PATCH /api/[ressource]/:id (Aktualisieren), DELETE /api/[ressource]/:id (Löschen). Halte es RESTful. Vermeide RPC-Stil-Endpoints, es sei denn, die Aktion passt wirklich nicht zu einer Ressource.

Eine gut strukturierte API macht es deinem WeWeb-Frontend oder FlutterFlow-App einfach, sich mit minimaler Konfiguration zu verbinden, und wenn du weitere Clients anbinden willst (z.B. eine Integration mit einem deutschen ERP-System wie SAP), ist deine API bereits bereit.

Authentifizierung und Autorisierung

Xanos integrierte Auth ist JWT-basiert und produktionsreif. Aktiviere das Auth-Add-on und du bekommst Registrierung, Login und Token-Erneuerung direkt aus der Box.

Für Autorisierung (was ein eingeloggter Nutzer tun kann) verwendest du den "Precondition"-Schritt in deinen Function Stacks. Ein typisches Muster: Hole den aktuellen Nutzer vom JWT, überprüfe dann, dass er den Datensatz besitzt, den er zu ändern versucht.

Für Admin-Rollen speicherst du ein Rollen-Feld in der Nutzertabelle und prüfst es in Vorbedingungen. Für Multi-Tenant speicherst du Workspace-Mitgliedschaft in einer separaten Tabelle und machst einen Join bei jeder Anfrage. Xanos JWT-Handling funktioniert nahtlos mit WeWebs Authentifizierungs-Plugin.

Geschäftslogik mit Function Stacks

Xanos Function Stack ist wo die Magie passiert. Jeder Schritt im Stack entspricht einer Operation: eine Datenbank abfragen, eine externe API aufrufen, eine Bedingung ausführen, Daten transformieren, eine E-Mail senden.

Für komplexe Logik verwendest du Xanos "Custom Function"-Funktion, um wiederverwendbare Bausteine zu erstellen. Wir bauen diese für: Preisberechnung, Validierung komplexer Eingaben, Versand von Benachrichtigungen und Synchronisation von Daten mit Dritten.

Vermeide tief verschachtelte Bedingungen, wenn dein Stack mehr als 3 Verschachtelungsebenen hat, refaktoriere in separate Funktionen. Diese Disziplin hält deine Xano-Instanz wartbar und übertragbar an den Kunden oder ein neues Team.

Drittanbieter-Integrationen

Xanos External API Request-Schritt verbindet sich mit beliebigen REST-APIs. Wir haben Stripe, Twilio, SendGrid, HubSpot, Airtable und Dutzende andere integriert.

Best Practice: Erstelle eine "Utility"-Funktion pro externem Service (z.B. "Stripe-Charge senden"), die den API-Aufruf, Fehlerbehandlung und Antwort-Parsing übernimmt. Dann rufst du dieses Utility aus deinen Geschäftslogik-Stacks auf, das hält deine Logik sauber und macht die Integration einfach zu aktualisieren.

Für deutsche SaaS-Unternehmen sind häufige Integrationen: DATEV (Buchhaltung), Lexoffice, sevDesk, Stripe für EUR-Zahlungen und Brevo (ehemals Sendinblue) für deutsche E-Mail-Zustellbarkeit. Xanos External API-Schritt verarbeitet all diese ohne Spezialcode.

Performance und Skalierung

Xano skaliert automatisch, kein Infrastruktur-Management erforderlich. Für Performance-Optimierung: Verwende Indizes für Felder, die du häufig abfragst (user_id, created_at, status), paginiere alle List-Endpoints und verwende Xanos Caching für Daten, die sich selten ändern.

Für verkehrsintensive Endpoints bieten Xanos bezahlte Pläne erhöhte Parallelität. Wir haben Apps mit 50.000 täglich aktiven Nutzern auf Xano ohne Performance-Probleme betrieben. Für deutsche SaaS-Unternehmen mit Wachstumsambitionen ist das eine komfortable Marge, du kannst dich auf Kundenakquise konzentrieren statt auf Infrastruktur-Tuning. <a href="/contact">Kontaktiere uns</a> für eine Architekturberatung.

Xano Middleware: Request-Preprocessing und globale Logik

Xano unterstützt Middleware über seine "Pre-run"- und "Post-run"-Hooks, Funktionen, die vor oder nach jedem Endpoint in einer API-Gruppe ausgeführt werden. Das ist der richtige Ort für Querschnittsthemen: jede Anfrage loggen, API-Keys für öffentliche Endpoints validieren, Rate Limiting nach IP oder Nutzer, und gemeinsamen Kontext wie den aktuellen Workspace aus dem JWT injizieren.

Wir verwenden ein Standard-Middleware-Muster auf allen Produktionsprojekten: Der Pre-run-Hook validiert das JWT, lädt den aktuellen Nutzer und Workspace in den Kontext und setzt ein globales Fehlerformat. Das bedeutet, jeder Geschäftslogik-Endpoint startet mit einem sauberen, authentifizierten Kontext, keine Wiederholung über 50 Endpoints hinweg.

Post-run-Hooks werden seltener gebraucht, sind aber nützlich für Audit-Logging. Für regulierte Branchen (Fintech, Healthtech) sollte jede Datenänderung einen Audit-Datensatz schreiben. Das in Post-run-Middleware zu bauen bedeutet, dass du es bei einem neuen Endpoint nicht versehentlich vergessen kannst.

Hintergrundaufgaben und asynchrone Verarbeitung

Nicht alles gehört in einen synchronen Request-Response-Zyklus. E-Mails senden, PDFs generieren, hochgeladene Dateien verarbeiten und mit Dritt-CRMs synchronisieren sollten alle asynchron sein. Xanos Background-Tasks-Feature lässt dich Funktionen auslösen, die außerhalb des HTTP-Request-Zyklus laufen, die API antwortet sofort, und die schwere Arbeit passiert im Hintergrund.

In unseren Projekten nutzen wir Hintergrundaufgaben für: Webhook-Verarbeitung (Stripe-Events brauchen Zeit zum Parsen und Aktualisieren), Massen-Datenimporte (CSV-Uploads mit Tausenden Zeilen) und geplante Jobs wie tägliche Zusammenfassungs-E-Mails oder Abo-Verlängerungsprüfungen. Xanos Task-Queue ist zuverlässig und beobachtbar, du siehst laufende und fehlgeschlagene Tasks im Dashboard und kannst sie bei Bedarf manuell erneut ausführen.

Für wirklich komplexe Zeitplanung (führe diese Funktion jeden Tag um 9 Uhr in der Zeitzone des Nutzers aus) integriert sich Xano sauber mit Make.com oder n8n als Scheduler, der deine Xano-Endpoints per Cron auslöst.

Umgebungsvariablen und Konfigurationsmanagement

Xano unterstützt Umgebungsvariablen auf Instanz- und API-Gruppen-Ebene. Speichere alle sensiblen Konfigurationen, OpenAI-API-Keys, Stripe-Secret-Keys, SendGrid-API-Keys, Twilio-Auth-Tokens, als Umgebungsvariablen, niemals direkt in deinen Function Stacks. Das ist eine Sicherheits-Grundlinie, die jedes produktive Xano-Projekt befolgen sollte.

Xano unterstützt außerdem mehrere Umgebungen über sein "Workspace Branch"-Feature (in bezahlten Plänen). Das erlaubt dir, separate Entwicklungs-, Staging- und Produktionsumgebungen mit unterschiedlichen Datenbankinstanzen und Umgebungsvariablen zu pflegen. In unserem Workflow werden alle neuen Features auf einem Dev-Branch gebaut, auf Staging getestet und in die Produktion gemerged, dieselbe git-ähnliche Disziplin wie in der traditionellen Entwicklung.

Ein praktischer Tipp: Präfixe deine Umgebungsvariablen-Namen mit dem Service-Namen (STRIPE_SECRET_KEY, OPENAI_API_KEY, SENDGRID_API_KEY). Bei 20+ Variablen sparen Namenskonventionen erhebliche Debugging-Zeit.

Xano vs. Supabase Edge Functions: Wann welches nutzen

Sowohl Xano als auch Supabase Edge Functions können Backend-Logik ausführen. Die richtige Wahl hängt davon ab, was du baust. Xano ist besser für: vollständiges REST-API-Management, komplexe mehrstufige Geschäftslogik, Apps, bei denen Nicht-Entwickler die Logik lesen oder ändern müssen, und alles, was Xanos visuellen Debugger benötigt. Supabase Edge Functions sind besser für: Datenbank-Trigger, die automatisch bei Datenänderungen laufen, leichtgewichtige Utility-Funktionen, die nah an der Datenbank leben, und Free-Tier-Projekte, bei denen Xanos Kosten nicht gerechtfertigt sind.

In den meisten App-Studio-Projekten nutzen wir beide: Xano als primäre API-Schicht (wo sich Frontend-Clients verbinden) und Supabase Edge Functions für datenbankgetriggerte Automatisierung. Wenn zum Beispiel ein neuer Abonnement-Datensatz in Supabase erstellt wird, sendet eine Edge Function sofort eine Willkommens-E-Mail, kein Polling oder externer Trigger nötig.

Die entscheidende Unterscheidung ist die Zielgruppe: Xano ist visuell und für Teams gebaut, bei denen Geschäftslogik für Nicht-Ingenieure lesbar sein muss. Supabase Edge Functions sind TypeScript/Deno und erfordern Entwicklerkontext. Für reine Entwickler-Teams funktioniert beides. Für Teams mit nicht-technischen Gründern, die die Logik verstehen und ändern wollen, gewinnt Xano eindeutig.

Xano-Preisstufen: Was du wirklich brauchst

Xano hat drei Hauptstufen: Free, Launch (99 USD/Monat) und Scale (249 USD/Monat). Die Free-Stufe ist nützlich zum Prototyping, hat aber keine Custom-Domain-Unterstützung für deine API und begrenzte Ausführungszeit, nutze sie nicht für die Produktion. Launch ist die richtige Stufe für die meisten frühphasigen SaaS-Produkte: Custom Domain, Background Tasks, verzweigte Umgebungen und ausreichende Parallelität für bis zu etwa 5.000 MAU.

Die Scale-Stufe fügt höhere Parallelität, dedizierte Ressourcen und Priority-Support hinzu. Wir upgraden Kunden auf Scale, wenn sie konsequent Parallelitätslimits erreichen (normalerweise um 10.000 bis 15.000 MAU bei Spitzennutzungsmustern) oder wenn ihre SLA dedizierte Infrastruktur erfordert.

Ein Kostenhinweis: Xano berechnet pro Instanz, nicht pro Sitzplatz. Eine einzelne Xano-Launch-Instanz hostet eine unbegrenzte Anzahl von APIs und Endpoints. Für Agenturen, die mehrere Kunden-Apps bauen, ist das äußerst kosteneffizient. Wir betreiben mehrere Kundenprojekte pro Xano-Instanz während MVP-Phasen und migrieren jedes zu einer dedizierten Instanz, wenn sie produktiven Maßstab erreichen.