Behöver man kunna koda för att använda Xano?

Nej, Xanos visuella function stack låter dig bygga komplex affärslogik utan kod. Du kopplar ihop steg för databaskörning, externa API-anrop, villkor och datatransformationer i ett dragbart gränssnitt. För verkligt komplexa beräkningar finns ett kodsteg om du vill, men de flesta SaaS-backend-behov täcks helt utan det.

Hur integrerar man Xano med svenska betaltjänster som Swish?

Xanos External API Request-steg ansluter till vilket REST-API som helst. Swish integreras via Swish Merchant API och BankGiro-betalningar via din bankpartner. Fortnox och Visma för bokföring har också REST-API:er som Xano hanterar direkt. Vi har byggt dessa integrationer för svenska SaaS-kunder utan att skriva en enda rad anpassad servercode.

Kan Xano hantera GDPR-krav kring datalagring?

Xano erbjuder EU-regionval för datalagring, vilket är ett grundläggande krav för att uppfylla GDPR och Schrems II. Din data stannar inom EU och du kan dokumentera dataflöden för ditt GDPR-register. För extra kontroll kan du kombinera Xano som API-lager med Supabase som databas, Supabase ger ännu finare kontroll med RLS och explicit EU-hosting.

Vad händer med min Xano-backend om jag vill byta till anpassad kod?

Xano exponerar standard REST-endpoints med väldefinierade JSON-svar. Din WeWeb-frontend eller FlutterFlow-mobilapp kommunicerar via dessa endpoints precis som med en handskriven backend. Om du en dag vill ersätta Xano med en custom backend behåller du din frontend intakt och byter bara ut API:et bakom, utan kundpåverkan.

Bygga ett skalbart REST-API med Xano

Sätta upp din datamodell

Börja med ditt databasschema innan du bygger några endpoints. Xanos visuella tabellbyggare stöder alla PostgreSQL-datatyper: text, heltal, boolean, JSON, tidsstämplar och filreferenser.

Nyckelkonventioner vi använder: varje tabell får en created_at och updated_at-tidsstämpel (Xano lägger till dessa automatiskt), använd heltals-ID:n för prestanda och använd JSON-fält sparsamt, normalisera när möjligt.

För multi-tenant SaaS bör varje tabell ha en user_id eller workspace_id-främmande nyckel. Detta håller din åtkomstkontrolllogik ren och konsekvent. I en typisk svensk B2B-SaaS, säg ett HR-system eller ett upphandlingsverktyg, innebär detta att varje organisation (kund) har sin isolerade datauppsättning, vilket är ett grundläggande GDPR-krav.

Strukturera dina API-endpoints

Xano autogenererar CRUD-endpoints för varje tabell. Men för produktionsappar vill du ha anpassade endpoints som hanterar affärslogik.

Vår namnkonvention: GET /api/[resurs] (lista), GET /api/[resurs]/:id (detalj), POST /api/[resurs] (skapa), PATCH /api/[resurs]/:id (uppdatera), DELETE /api/[resurs]/:id (ta bort). Håll det RESTful. Undvik RPC-stil-endpoints om inte åtgärden verkligen inte mappar till en resurs.

En välstrukturerad API-design gör att din WeWeb-frontend eller FlutterFlow-mobilapp kan ansluta med minimal konfiguration, och när du eventuellt vill ansluta fler klienter (t.ex. en extern integration mot ett svenskt ERP-system) är din API redan redo för det.

Autentisering och auktorisering

Xanos inbyggda auth är JWT-baserad och produktionsklar. Aktivera auth-tillägget och du får registrering, inloggning och tokenförnyelse direkt ur lådan.

För auktorisering (vad en inloggad användare kan göra) använder du "Precondition"-steget i dina funktionsstackar. Ett typiskt mönster: hämta den nuvarande användaren från JWT, verifiera sedan att de äger den post de försöker ändra.

För adminroller lagrar du ett rollfält i användartabellen och kontrollerar det i förutsättningar. För multi-tenant lagrar du workspace-medlemskap i en separat tabell och gör join vid varje begäran. Xanos JWT-hantering fungerar sömlöst med WeWebs autentiseringsplugin.

Affärslogik med funktionsstackar

Xanos funktionsstack är där magin händer. Varje steg i stacken mappar till en operation: fråga en databas, anropa ett externt API, kör ett villkor, transformera data, skicka ett e-postmeddelande.

För komplex logik använder du Xanos "Custom Function"-funktion för att skapa återanvändbara byggblock. Vi bygger dessa för: beräkning av priser, validering av komplexa indata, skickande av notiser och synkronisering av data med tredje parter.

Undvik djupt nästlade villkor, om din stack har mer än 3 nivåer av nästling, refaktorera till separata funktioner. Den här disciplinen håller din Xano-instans underhållsbar och möjlig att överlämna till klienten eller ett nytt team.

Tredjepartsintegrationer

Xanos External API Request-steg ansluter till valfritt REST-API. Vi har integrerat Stripe, Twilio, SendGrid, HubSpot, Airtable och dussintals andra.

Bästa praxis: skapa en "utility"-funktion per extern tjänst (t.ex. "Skicka Stripe-debitering") som hanterar API-anropet, felhantering och svarsparsning. Anropa sedan detta utility från dina affärslogikstackar, det håller din logik ren och gör integrationen enkel att uppdatera.

För svenska SaaS-bolag är vanliga integrationer: Fortnox (bokföring), Visma, BankID (via en BankID-proxy-API), Kivra och Swish. Xanos External API-steg hanterar alla dessa utan specialkod.

Prestanda och skalning

Xano skalar automatiskt, ingen infrastrukturhantering krävs. För prestandaoptimering: använd index på fält du frågar ofta (user_id, created_at, status), paginera alla listendpoints (använd Xanos inbyggda offset/limit eller markörpaginering) och använd Xanos caching för data som inte ändras ofta.

För trafiktung endpoints erbjuder Xanos betalplaner ökad samtidighet. Vi har kört appar med 50 000 dagliga aktiva användare på Xano utan prestandaproblem. För svenska SaaS-bolag med tillväxtambitioner är detta en bekväm marginal, du kan fokusera på kundanskaffning istället för infrastrukturtrimning.

Xano-middleware: förbearbetning av förfrågningar och global logik

Xano stöder middleware via sina "Pre-run"- och "Post-run"-hooks, funktioner som körs före eller efter varje endpoint i en API-grupp. Det här är rätt plats för tvärgående bekymmer: loggning av varje förfrågan, validering av API-nycklar för publika endpoints, hastighetsbegränsning per IP eller användare, och injicering av gemensam kontext, som den aktuella workspacen, från JWT:n.

Vi använder ett standardiserat middleware-mönster på alla produktionsprojekt: pre-run-hooken validerar JWT:n, laddar den aktuella användaren och workspacen till kontexten och sätter ett globalt felformat. Det innebär att varje affärslogik-endpoint startar med en ren, autentiserad kontext, ingen upprepning över 50 endpoints.

Post-run-hooks behövs mer sällan men är användbara för granskningsloggning (audit logging). För reglerade branscher (fintech, healthtech) bör varje datamutation skriva en granskningspost. Att bygga in detta i post-run-middleware innebär att du inte kan glömma det av misstag på en ny endpoint.

Bakgrundsuppgifter och asynkron bearbetning

Allt hör inte hemma i en synkron request-response-cykel. Att skicka e-post, generera PDF:er, bearbeta uppladdade filer och synkronisera med tredjeparts-CRM:er bör alla vara asynkrona. Xanos Background Tasks-funktion låter dig utlösa funktioner som körs utanför HTTP-förfrågningscykeln, API:et svarar direkt och det tunga arbetet sker i bakgrunden.

I våra projekt använder vi bakgrundsuppgifter för: webhook-bearbetning (Stripe-händelser tar tid att tolka och uppdatera), massimport av data (CSV-uppladdningar med tusentals rader) och schemalagda jobb som dagliga sammanfattnings-mejl eller kontroller av abonnemangsförnyelser. Xanos task-kö är pålitlig och observerbar, du kan se pågående och misslyckade uppgifter i dashboarden och köra om dem manuellt vid behov.

För verkligt komplex schemaläggning (kör den här funktionen varje dag klockan 9 i användarens tidszon) integrerar Xano smidigt med Make.com eller n8n som schemaläggare som utlöser dina Xano-endpoints via cron.

Miljövariabler och konfigurationshantering

Xano stöder miljövariabler på instans- och API-gruppnivå. Lagra all känslig konfiguration, OpenAI-API-nycklar, Stripe-hemliga nycklar, SendGrid-API-nycklar, Twilio-autentiseringstoken, som miljövariabler, aldrig direkt i dina funktionsstackar. Det här är en säkerhetsbaslinje som varje produktions-Xano-projekt bör följa.

Xano stöder också flera miljöer via sin "Workspace Branch"-funktion (på betalplaner). Det låter dig upprätthålla separata utvecklings-, staging- och produktionsmiljöer med olika databasinstanser och miljövariabler. I vårt arbetsflöde byggs alla nya funktioner på en dev-branch, testas på staging och slås samman till produktion, samma git-liknande disciplin som traditionell utveckling.

Ett praktiskt tips: prefixa dina miljövariabelnamn med tjänstens namn (STRIPE_SECRET_KEY, OPENAI_API_KEY, SENDGRID_API_KEY). När du har 20+ variabler sparar namnkonventioner betydande felsökningstid.

Xano vs Supabase Edge Functions: när ska du använda vilken?

Både Xano och Supabase Edge Functions kan köra backend-logik. Rätt val beror på vad du bygger. Xano är bättre för: full REST API-hantering, komplex flerstegs affärslogik, appar där icke-utvecklare behöver läsa eller ändra logiken, och allt som kräver Xanos visuella debugger. Supabase Edge Functions är bättre för: databastriggers som körs automatiskt vid dataändringar, lättviktiga hjälpfunktioner som lever nära databasen, och projekt i gratisnivån där Xanos kostnad inte är motiverad.

I de flesta App Studio-projekt använder vi båda: Xano som det primära API-lagret (där frontend-klienter ansluter) och Supabase Edge Functions för databasutlöst automation. Till exempel, när en ny abonnemangspost skapas i Supabase skickar en Edge Function omedelbart ett välkomstmejl, ingen polling eller extern trigger behövs.

Den viktigaste skillnaden är målgruppen: Xano är visuellt och byggt för team där affärslogiken behöver vara läsbar för icke-ingenjörer. Supabase Edge Functions är TypeScript/Deno och kräver utvecklarkontext. För rena utvecklarteam fungerar båda. För team med icke-tekniska grundare som vill förstå och ändra logiken vinner Xano tydligt.

Xanos prisnivåer: vad du faktiskt behöver

Xano har tre huvudnivåer: Free, Launch ($99/månad) och Scale ($249/månad). Free-nivån är användbar för prototyper men saknar stöd för anpassad domän för ditt API och har begränsad exekveringstid, använd den inte i produktion. Launch är rätt nivå för de flesta tidiga SaaS-produkter: anpassad domän, bakgrundsuppgifter, branch-miljöer och tillräcklig samtidighet för upp till cirka 5 000 MAU.

Scale-nivån lägger till högre samtidighet, dedikerade resurser och prioriterad support. Vi uppgraderar kunder till Scale när de konsekvent når samtidighetsgränser (vanligtvis runt 10 000-15 000 MAU med toppanvändningsmönster) eller när deras SLA kräver dedikerad infrastruktur.

En kostnadsanteckning: Xano tar betalt per instans, inte per plats (seat). En enda Xano Launch-instans hostar ett obegränsat antal API:er och endpoints. För byråer som bygger flera klientappar är detta extremt kostnadseffektivt. Vi kör flera klientprojekt per Xano-instans under MVP-faser och migrerar varje till en dedikerad instans när de når produktionsskala.

Bygga ett skalbart REST-API med Xano: En komplett guide