Ditt WhatsApp Flow fungerar … tills det rör något känsligt. Bokningsbara tider, platsval, kunduppgifter. Då kommer frågorna: ”Är det krypterat?”, ”Kan vi lita på payloaden?”, ”Vad händer om någon manipulerar svaret?” Säker meddelandehantering ska inte innebära skör meddelandehantering.
Den här WhatsApp PostgreSQL-automationen slår först mot supportteam, men produktägare som levererar Flow-baserade upplevelser känner av det också. Och om du driver ett litet ops-team vet du redan hur snabbt ”bara ett Flow” blir ett projekt för säkerhet och driftsäkerhet. Målet här är enkelt: krypterade förfrågningar in, krypterade svar ut, med riktig data hämtad från PostgreSQL.
Nedan ser du hur workflowet tar emot WhatsApp Flow-payloads, dekrypterar dem, routar varje skärm och returnerar krypterade svar som WhatsApp-klienten faktiskt kan använda.
Så fungerar automationen
Hela n8n-workflowet, från trigger till slutlig output:
n8n Workflow Template: WhatsApp + PostgreSQL: säkra Flow-svar som funkar
flowchart LR
subgraph sg0["Flow 1"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Webhook1"]
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Json Parser"]
n2@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Switch", pos: "b", h: 48 }
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Respond to Webhook1"]
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Data Extraction Code"]
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Respond to Webhook2"]
n6["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Data Extraction Code1"]
n7["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>move to base64"]
n8["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Decryption Code"]
n9["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Encrypt Return"]
n10["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Encrypt Return1"]
n2 --> n4
n2 --> n6
n0 --> n7
n1 --> n2
n9 --> n3
n7 --> n8
n8 --> n1
n10 --> n5
n4 --> n9
n6 --> n10
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n2 decision
class n0,n3,n5 api
class n1,n4,n6,n7,n8,n9,n10 code
classDef customIcon fill:none,stroke:none
class n0,n1,n3,n4,n5,n6,n7,n8,n9,n10 customIcon
Problemet: WhatsApp Flows fallerar när säkerhet möter riktig data
WhatsApp Flows är bra på att guida en kund genom steg, men så fort du kopplar dem till live-system blir det rörigt. Data kommer in krypterad, ditt backend förväntar sig korrekt formaterad JSON, och plötsligt skriver du limkod som ingen vill äga. Om du ”tillfälligt” skippar kryptering för att få fart skapar du ett compliance-problem och ett förtroendeproblem hos användarna. Och om Flow-svaren misslyckas ens en gång försöker kunder igen, supporten blir överbelastad och du tappar förtroendet för kanalen.
Det bygger snabbt på. Här är var det vanligtvis brister i den dagliga driften.
- Team kopierar ”exempel-kod för kryptering” in i slumpmässiga tjänster, vilket blir omöjligt att revidera i efterhand.
- En enda mismatch i payload-formatering kan göra att Flow-skärmen misslyckas utan att synas, så supporten får bara höra om det när kunder klagar.
- Databasuppslag läggs på sist, och nu har du två problem: säker transport och pålitliga PostgreSQL-frågor.
- När routing mellan Flow-skärmar hanteras manuellt blir små logikändringar till riskfyllda driftsättningar.
Lösningen: krypterad routing av WhatsApp Flow med PostgreSQL-backade svar
Det här workflowet ger dig ett rent, repeterbart mönster för att hantera WhatsApp Flows krypterade datautbyte i n8n. Det börjar med att ta emot den krypterade payloaden från WhatsApp på en webhook-endpoint. Sedan konverterar det inkommande värden till base64-buffertar, dekrypterar AES-nyckeln med din privata RSA-nyckel och dekrypterar payloaden med AES-GCM. När JSON:en är läsbar routar workflowet förfrågan baserat på Flowets screen-värde, kör rätt affärslogik (som att aggregera bokningsbara tider eller hämta en platslista) och krypterar till sist svaret igen med samma AES-nyckel och den inverterade IV:n så att WhatsApp-klienten kan lita på det.
Workflowet startar när WhatsApp anropar din n8n-webhook med krypterade fält. Därefter dekrypterar och parsar n8n payloaden, och sedan routar en switch till rätt skärmhanterare. Till sist krypteras svaret och skickas tillbaka via ”Respond to Webhook” så att Flowet kan rendera nästa skärm utan manuell handpåläggning.
Det du får: automation vs. resultat
| Vad det här workflowet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att ditt Flow har två skärmar som behöver live-data: ”Välj en tid” och ”Välj en plats.” Utan automation hamnar en utvecklare ofta i att underhålla två separata endpoints plus krypteringskod, och sedan felsöka payload-problem när WhatsApp ändrar något. Det är lätt runt 2 timmar i veckan av ”varför failade den här skärmen”-jobb. Med det här workflowet delar båda skärmarna samma dekryptera → routa → kryptera-ryggrad, så att lägga till en ny skärm är oftast bara en ny gren och en svarbyggare.
Det du behöver
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- WhatsApp Business API / WhatsApp Cloud API för att skicka krypterade Flow-förfrågningar
- PostgreSQL för uppslag av tider och platser
- RSA-nyckelpar (generera en 2048-bitars nyckel; registrera den publika nyckeln hos WhatsApp)
Kunskapsnivå: Medel. Du bygger ingen app, men du behöver vara bekväm med att klistra in nycklar, testa webhooks och läsa loggar när krypteringen fallerar.
Vill du inte sätta upp det här själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
Krypterad webhook kommer in. WhatsApp anropar din n8n-webhook med tre nyckeldelar: den krypterade payloaden, en RSA-krypterad AES-nyckel och initialiseringsvektorn (IV).
Dekryptering och parsning sker i n8n. Workflowet konverterar de inkommande fälten till rätt base64-/binärformat, dekrypterar AES-nyckeln med din privata RSA-nyckel och dekrypterar payloaden med AES-GCM. Sedan parsar det JSON:en så att du kan jobba med vanliga fält som screen och användarens val.
Skärmbaserad routing väljer rätt hanterare. En Switch-nod routar förfrågan baserat på parametern screen. För en route aggregerar workflowet bokningsbara tider (typiskt backat av en PostgreSQL-fråga i din egen version). För en annan route hämtar det platslistan och förbereder rätt svarsstruktur.
Krypterat svar går tillbaka direkt. Workflowet krypterar svaret med samma AES-nyckel och en inverterad IV, och sedan returnerar Respond to Webhook det base64-kodade krypterade svaret som WhatsApp förväntar sig.
Du kan enkelt ändra skärm-routes för att stödja fler skärmar utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: Konfigurera webhook-triggern
Det här arbetsflödet startar när krypterad data skickas till en webhook-endpoint.
- Lägg till noden Incoming Webhook Trigger och ställ in HTTP Method på
POST. - Ställ in Path på
flow. - Ställ in Response Mode på
responseNodeså att responsnoder kan returnera krypterad data. - Under Options → Response Headers lägger ni till Content-Type med värdet
text/plain.
Steg 2: Koppla inkommande databehandling
Konvertera, dekryptera och parsa inkommande payload så att arbetsflödet kan routa förfrågan och svara korrekt.
- Lägg till Convert To Base64 Buffers och klistra in den tillhandahållna JavaScript Code som konverterar
encrypted_flow_data,encrypted_aes_keyochinitial_vectorfrån$json.bodytill buffertar. - Lägg till Decrypt Payload och klistra in den tillhandahållna JavaScript Code. Ersätt platshållarblocket för privat nyckel som börjar med
-----BEGIN PRIVATE KEY-----. - Lägg till Parse JSON Payload och klistra in den tillhandahållna JavaScript Code för att extrahera
date,screenochflow_tokenfrån den dekrypterade payloaden. - Behåll Flowpast Branding som en valfri klisterlapp för dokumentation; den påverkar inte körningen.
[INSERT YOUR KEY HERE] i blocket för privat nyckel eller om de inkommande fälten inte är giltig Base64.Steg 3: Konfigurera villkorsstyrd routing
Arbetsflödet routar svar baserat på värdet screen i den dekrypterade payloaden.
- I Route by Condition lägger ni till en regel som kontrollerar att Left Value
={{ $json.screen }}är lika medAPPOINTMENT. - Lägg till en andra regel som kontrollerar att Left Value
={{ $json.screen }}är lika medDATE_SELECTION_SCREEN. - Koppla första utgången till Aggregate Appointment Slots och den andra utgången till Extract Seat List (detta är villkorsgrenar, inte parallella).
Steg 4: Konfigurera svarsflödet för bokning
Den här vägen aggregerar bokningsdata och skickar ett krypterat svar för bokningsskärmen.
- I Aggregate Appointment Slots behåller ni den tillhandahållna JavaScript Code som grupperar objekt efter
appointment_dateoch samlar instart_time-värden. - I Encrypt Appointment Reply behåller ni den tillhandahållna JavaScript Code som läser IV från Convert To Base64 Buffers, AES-nyckeln från Decrypt Payload och sätter
screentillAPPOINTMENT. - I Send Webhook Response A ställer ni in Respond With på
textoch Response Body på={{ $json.body }}.
Steg 5: Konfigurera svarsflödet för platsval
Den här vägen extraherar platsvärden och skickar ett krypterat svar för sammanfattningsskärmen.
- I Extract Seat List behåller ni den tillhandahållna JavaScript Code som parsar
decryptedPayload.data.seatsoch returnerar varje plats som ett objekt. - I Encrypt Seat Reply behåller ni den tillhandahållna JavaScript Code som använder AES-nyckeln från Decrypt Payload och sätter
screentillSUMMARY. - I Send Webhook Response B ställer ni in Respond With på
textoch Response Body på={{ $json.body }}.
Steg 6: Testa och aktivera ert arbetsflöde
Verifiera att arbetsflödet dekrypterar, routar och svarar med krypterad data innan ni aktiverar det för produktion.
- Klicka på Test Workflow och skicka en
POST-begäran till Incoming Webhook Trigger-URL:en medencrypted_flow_data,encrypted_aes_keyochinitial_vectori body. - Bekräfta att körningen går från Convert To Base64 Buffers → Decrypt Payload → Parse JSON Payload → Route by Condition.
- För
APPOINTMENT-skärmar verifierar ni att Send Webhook Response A returnerar en Base64-sträng; förDATE_SELECTION_SCREENverifierar ni att Send Webhook Response B returnerar en Base64-sträng. - Slå på arbetsflödet till Active för att ta emot live-krypterade förfrågningar.
Vanliga fallgropar
- WhatsApp Cloud API:s krypteringssetup är inte förlåtande. Om svar plötsligt slutar fungera, kontrollera igen att din registrerade publika nyckel fortfarande är ”active” i inställningarna för ditt WhatsApp Business-konto.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in ditt varumärkes tonalitet tidigt, annars kommer du att redigera output för alltid.
Vanliga frågor
Cirka en timme om dina WhatsApp-nycklar och din Postgres-åtkomst är redo.
Nej, inte för grunduppsättningen. Du kommer främst att konfigurera credentials, lägga till din Postgres-fråga och testa med riktiga Flow-skärmar.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in kostnader för WhatsApp Cloud API samt dina kostnader för VPS/databashosting.
Två alternativ: n8n Cloud (hanterat, enklast setup) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärt och hanterar n8n bra. Self-hosting ger dig obegränsade körningar men kräver grundläggande serveradministration.
Ja. Du kan lägga till en ny route i switchen ”Route by Condition” och sedan duplicera mönstret som används av ”Aggregate Appointment Slots” eller ”Extract Seat List” för att bygga och kryptera ett svar för den skärmen. Vanliga anpassningar är att lägga till en skärm för ”bekräfta uppgifter”, hämta andra fält från PostgreSQL och returnera olika svarsformat per skärm.
Oftast är det en mismatch mellan den publika nyckeln som är registrerad i WhatsApp och den privata nyckeln som används i n8n. Kontrollera också att den inkommande payloaden innehåller de förväntade krypterade fälten och att din webhook-URL matchar det WhatsApp anropar. Om det fungerar ibland och fallerar vid belastning kan du slå i rate limits eller få timingproblem, så gå igenom webhook-loggar och retry-beteende. Ärligt talat beror de flesta ”mystiska fel” på nyckelns registreringsstatus eller en liten formateringsändring i den dekrypterade JSON:en.
På en liten VPS hanterar de flesta team hundratals Flow-förfrågningar per dag utan att ens tänka på det.
För krypteringstunga WhatsApp Flows är n8n oftast ett bättre val eftersom du kan köra kodsteg, styra branching och self-hosta vid behov. Zapier och Make är utmärkta för enkla automationer i stil med ”skicka meddelande när en rad ändras”, men de är inte byggda för att implementera WhatsApps Business Encryption-protokoll end-to-end. Med n8n kan du hålla logiken för dekryptera/routa/kryptera i ett workflow och inspektera varje steg när något ser fel ut. Det är också enklare att bygga ut: lägg till en ny skärm-route, lägg till en Postgres-fråga, leverera. Prata med en automationsexpert om du vill ha en snabb rekommendation baserat på din volym och dina compliance-krav.
Du får ett WhatsApp Flow som både är säkert och pålitligt, vilket egentligen är hela poängen. Sätt upp det en gång och fokusera sedan på kundupplevelsen i stället för att släcka krypteringsbränder.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.