n8n webhook POST i Respond to Webhook – jak zbudować synchroniczne API

Webhook GET zwraca dane. Webhook POST je przyjmuje, przetwarza i powinnien coś odesłać z powrotem. Ten “coś z powrotem” to właśnie miejsce, gdzie wiekszość osób po raz pierwszy napotyka błąd: “No respond to webhook node found in the workflow”. Brzmi jak problem, ale w praktyce to najlepsza lekcja o różnicy między asynchronicznym powiadomieniem a synchronicznym API. W tym artykule budujesz endpoint POST w n8n krok po kroku: od konfiguracji webhooka przez zapis do Data Tables po węzeł Respond to Webhook, który odsyła klientowi precyzyjną odpowiedź JSON. Po drodze omawiamy też standaryzację danych z JavaScript, logikę Insert vs Update i higienę pracy z URL testowymi i produkcyjnymi.

Co to jest “Respond to Webhook” i dlaczego zmienia sposób działania API?

Tryb “Respond to Webhook” zmienia webhook w n8n z jednostronnego odbiorcy w pełnoprawne synchroniczne API: odbiera zapytanie, wykonuje pracę i dopiero po jej zakończeniu odsyła odpowiedź.

Domyślnie webhook n8n działa w trybie “Immediately” – odbiera zapytanie i od razu odsyła potwierdzenie “dostałem, przetwarzam”, nie czekając na wynik. Dla prostych powiadomień to wystarczy. Jednak gdy klient (np. Postman lub aplikacja frontendowa) potrzebuje wiedziec, czy rekord został zapisany poprawnie albo jaki ID otrzymał nowy wpis, “Immediately” nie wystarczy. Klient trzyma “słuchawkę” otwartą i czeka na realną odpowiedź.

Zmiana trybu na “Using Respond to Webhook Node” oddaje Ci pełną kontrolę nad odpowiedzią. Możesz najpierw zapisać dane w bazie, przetworzyć je przez JavaScript, a dopiero potem skonstruować i wysłać klientowi dokładnie to, co chcesz. To fundament profesjonalnych endpointów POST w n8n.

Bez węzła Respond to Webhook n8n zgłosi błąd o brakującym węźle odpowiedzi. To celowe zachowanie platformy – system daje znać, że klient czeka i bez węzła Respond workflow jest niekompletny.

Krok po kroku: webhook POST z zapisem do Data Tables

Poniższy workflow przyjmuje dane przez POST, zapisuje rekord w Data Tables i zwraca potwierdzenie z ID nowego wpisu. Punktem wyjścia jest tabela products w Data Tables z dwiema kolumnami: productName i price.

Tabela gotowa. Czas na workflow – trzy węzły na canvasie, które razem tworzą kompletny endpoint POST.

Konfiguracja węzła Webhook

Dodaj węzeł Webhook na canvas. Ustaw HTTP Method na POST. W sekcji Response Mode zmień “Immediately” na “Using Respond to Webhook Node”. Nadaj czytelną ścieżkę, np. add-record.

Dzięki tej zmianie n8n nie wyśle żadnej automatycznej odpowiedzi. Cały workflow musi zakończyc się węzłem Respond to Webhook, który sam zdefiniujesz.

Węzeł Data Tables Insert row

Po węźle Webhook dodaj węzeł Data Tables z operacją Insert row. Wskaż swoją tabelę i zmapuj kolumny:

• Kolumna productName – wartość z body zapytania: {{ $json.body.productName }}
• Kolumna price – wartość z body zapytania: {{ $json.body.price }}

Jeśli przeszedłeś przez artykuł o n8n webhook GET i Data Tables, wiesz już jak działają wyrażenia dynamiczne. Tutaj zamiast $json.query.id (parametr URL) używasz $json.body.productName (parametr z ciała zapytania POST).

Węzeł Respond to Webhook

Na końcu workflow dodaj węzeł Respond to Webhook. W polu Response Body skonstruuj odpowiedź JSON, która wróci do klienta. Minimalna odpowiedź potwierdzająca zapis wygląda tak:

{
  "success": true,
  "message": "Rekord zapisany",
  "id": "{{ $json.id }}"
}

Wartość $json.id pochodzi z Data Tables, które po operacji Insert row zwracają ID nowo utworzonego rekordu. Dzięki temu klient natychmiast wie, pod jakim identyfikatorem leży jego wpis.

Kumulacja danych i standaryzacja z JavaScript

Jedna z najważniejszych właściwości n8n: dane z każdego poprzedniego węzła są dostepne we wszystkich kolejnych. Nie tracisz danych przechodząc przez węzły – wszystko kumuluje sie w jednym strumieniu. Dlatego w węźle Respond to Webhook możesz jednocześnie sięgnąć po ID z Data Tables i po oryginalne name z webhooka – nawet jeśli między nimi był węzeł Code transformujący dane.

Ta “superpower” szczególnie przydaje sie przy standaryzacji danych. Zanim zapiszesz rekord w bazie, możesz przepuścic dane przez węzeł Code, który ujednolici ich format. Przykład: parseFloat() i .toFixed(2) zamieniają cenę na liczbę z dokładnie dwoma miejscami po przecinku przed zapisem.

return $input.all().map(item => ({
  json: {
    productName: item.json.body.productName.trim(),
    price: parseFloat(item.json.body.price).toFixed(2)
  }
}));

Ten fragment JavaScript przyjmuje wszystkie elementy wejściowe, mapuje je na nową strukturę z productName oczyszczonym ze zbędnych spacji (.trim()) i price zaokrąglonym do dwóch miejsc po przecinku, i zwraca tablicę obiektów (taki format n8n wymaga na wyjściu węzła Code). Po tym węźle Data Tables Insert row pobiera oba pola ze strumienia danych.

Standaryzacja eliminuje klasyczny problem: baza pełna wpisów “29.9”, “29.90”, “29.900” – technicznie różnych, ale oznaczających tę samą cenę.

Insert vs Update – inteligentna logika zapisywania

Naiwny endpoint POST zawsze tworzy nowy rekord, niezależnie od tego, czy taki już istnieje. To prosta droga do duplikatów w bazie. Profesjonalny system sprawdza najpierw, czy rekord o danym ID już istnieje, i na tej podstawie wybiera operacje:

• Jeśli ID istnieje w tabeli – wykonaj Update (zaktualizuj istniejący rekord)
• Jeśli ID nie istnieje – wykonaj Insert (stwórz nowy rekord)

W n8n realizujesz to przez węzeł If/Else po operacji Data Tables Get rows. Warunek: “czy tablica wynikowa ma elementy?”. Gałąź “true” kieruje do Update, gałąź “false” do Insert. Obie gałęzie zbiegają sie w węźle Respond to Webhook, który odsyła odpowiedź z wynikiem.

Dlaczego operować na ID zamiast na nazwie? Nazwa jest podatna na case sensitivity i literówki. ID to liczbowy, unikalny identyfikator generowany przez Data Tables – system nigdy nie wygeneruje dwóch rekordów o tym samym ID. Podstawowy rekord musi trafic do bazy przez Insert, a każda późniejsza zmiana przez Update na jego ID.

Test URL vs Production URL – higiena pracy

N8n generuje dla każdego webhooka dwa adresy: testowy i produkcyjny. Różnią sie fragmentem URL (`webhook-test` vs `webhook`). Podczas budowania zawsze używaj testowego – nie wymaga aktywnego workflow i oddziela testowe wykonania od historii produkcyjnej. Efekt poprawnego wywołania endpointu widac od razu w Data Tables – nowy rekord pojawia sie natychmiast.

Rekord w tabeli to potwierdzenie ze strony bazy danych. Drugi sygnał sukcesu to sam węzeł Respond to Webhook – odpowiedź JSON odesłana klientowi z potwierdzeniem i ID.

Widac to w widoku Executions: wywołania przez Test URL pojawiają sie z etykietą “Manual Execution”. Producyjne – bez etykiety. Dzięki temu po kilku tygodniach od uruchomienia możesz jednoznacznie powiedzieć, które wykonania były częscią testów, a które to rzeczywisty ruch.

Dodatkowy sygnał: aktywny workflow produkcyjny ma zieloną lampkę w panelu Workflows. Nieaktywny workflow nie odpowiada na produkcyjnym URL, tylko na testowym (gdy jesteś w edytorze). To prosta, ale ważna różnica, o której warto pamiętać zanim podzielisz sie endpointem z zespołem. Więcej o historii wykonań i debugowaniu znajdziesz w artykule o Executions w n8n.

Kurs n8n 2.0 · Kodożercy

Chcesz budować agenty AI? Zacznij od n8n

n8n to platforma, na której działają prawdziwe agenty AI: pobierają dane, podejmują decyzje, wykonują zadania. Kurs n8n 2.0 na Kodożercach przeprowadzi Cię przez budowanie pierwszego agenta.

Sprawdź jak to działa →

FAQ – Najczęstsze pytania o webhook POST i Respond to Webhook w n8n

Dlaczego n8n zgłasza błąd o brakującym węźle odpowiedzi?

Ten błąd pojawia sie gdy tryb odpowiedzi webhooka jest ustawiony na “Using Respond to Webhook Node”, ale w workflow nie ma węzła Respond to Webhook. N8n nie wie, co odesłac klientowi – dlatego zgłasza błąd. Rozwiązanie: dodaj węzeł Respond to Webhook na końcu workflow (lub na końcu każdej gałęzi, jeśli workflow ma rozgałęzienia).

Czy mogę używac trybu “Immediately” i Respond to Webhook jednocześnie?

Nie. Tryb webhooka to albo “Immediately” (automatyczna natychmiastowa odpowiedź) albo “Using Respond to Webhook Node” (ręcznie zdefiniowana odpowiedź). Przy pierwszym trybie węzeł Respond to Webhook jest ignorowany. Przy drugim jest wymagany.

Skąd w węźle Respond to Webhook pobrać ID nowo utworzonego rekordu?

Po operacji Data Tables Insert row węzeł zwraca obiekt z polem id nowego rekordu. W węźle Respond to Webhook odwołujesz sie do niego przez {{ $json.id }} (jeśli bezpośrednio po Insert) lub przez {{ $('Data Tables').item.json.id }} (jeśli odwołujesz sie z innego miejsca workflow). Kumulacja danych sprawia, ze ID jest dostepne we wszystkich kolejnych węzłach.

Kiedy używac Insert, a kiedy Update w Data Tables?

Insert tworzy nowy rekord. Update nadpisuje istniejący na podstawie ID. Jeśli budujesz endpoint, który może otrzymac ten sam rekord wielokrotnie (np. synchronizacja danych), użyj logiki: sprawdź czy rekord o danym ID istnieje (Data Tables Get rows), jeśli tak – Update, jeśli nie – Insert. Dzięki temu unikasz duplikatów.

Jak wygląda body zapytania POST, które webhook n8n odczytuje?

Webhook POST w n8n oczekuje danych w formacie JSON w ciele zapytania (Content-Type: application/json). Przykład: {"productName": "Widget A", "price": 29.99}. W wyrażeniach odwołujesz sie do tych danych przez $json.body.productName i $json.body.price. Możesz to przetestowac w Postmanie, o czym piszę w artykule o testowaniu API w Postmanie.

Podsumowanie

Webhook POST w trybie “Using Respond to Webhook Node” zmienia n8n z jednostronnego odbiorcy w synchroniczne API: odbiera dane, przetwarza je i odsyła klientowi precyzyjną odpowiedź JSON. Trzy węzły tworzą kompletny endpoint: Webhook przyjmuje body zapytania, Data Tables Insert row zapisuje rekord, Respond to Webhook odsyła potwierdzenie z ID. Kumulacja danych pozwala sięgac po wartości z dowolnego wcześniejszego etapu, co przydaje sie przy standaryzacji przez JavaScript przed zapisem. Logika Insert vs Update na podstawie ID eliminuje duplikaty i jest standardem w profesjonalnych systemach. Przy pracy pamiętaj o rozróżnieniu Test URL (do budowania i testowania) i Production URL (dla realnego ruchu). Razem z poprzednim artykułem o webhook GET i Data Tables masz kompletny fundament własnego API w n8n bez pisania backendu. Pełny przewodnik po automatyzacji n8n znajdziesz na automatyzacja n8n – kompletny przewodnik.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.