Webhook Cepat, Proses Belakangan: Pola Asynchro…

Webhook sering dipakai sebagai pintu masuk workflow n8n: sebuah aplikasi mengirim data, lalu n8n memprosesnya. Masalah muncul ketika proses di belakangnya tidak sederhana. Misalnya, satu pesanan harus disimpan ke database, dikirim ke layanan pembayaran, dibuatkan invoice, lalu diteruskan ke WhatsApp. Jika semua langkah dikerjakan sebelum webhook menjawab, aplikasi pengirim bisa menunggu terlalu lama atau menganggap permintaan gagal.

Di sinilah pola asynchronous processing berguna. Intinya sederhana: webhook menerima dan mencatat permintaan terlebih dahulu, mengirim respons cepat, lalu pekerjaan lanjutan berjalan setelahnya. Pengguna tidak perlu menunggu seluruh rantai proses selesai hanya untuk mendapatkan konfirmasi bahwa permintaannya sudah diterima.

Bedakan “diterima” dan “selesai”

Banyak workflow mencampur dua hal yang sebenarnya berbeda: menerima permintaan dan menyelesaikan pekerjaan. Padahal, sebuah sistem bisa menjawab, “Data sudah kami terima,” meskipun proses berikutnya masih berlangsung.

Dalam n8n, Webhook node menyediakan beberapa cara untuk merespons. Mode Immediately mengirim respons ketika workflow dimulai. Mode When Last Node Finishes menunggu hingga node terakhir selesai. Ada juga mode Using 'Respond to Webhook' Node jika kita ingin menentukan kapan dan seperti apa respons dikirim. ([docs.n8n.io](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/))

Untuk proses yang ringan—misalnya menerima data formulir lalu mengembalikan hasil validasi sederhana—menunggu sampai node terakhir selesai masih masuk akal. Namun, untuk proses yang memanggil beberapa API, mengunggah file, atau menunggu persetujuan manusia, respons langsung biasanya lebih tepat.

Contoh alur sederhana

Bayangkan sebuah toko online mengirim data pesanan ke webhook n8n. Payload-nya berisi nomor pesanan, identitas pelanggan, dan daftar barang. Workflow dapat dirancang seperti ini:

Webhook menerima permintaan. n8n membaca payload dan mengambil ID transaksi.
Data minimum disimpan. Simpan pesanan dengan status received atau processing.
Respons cepat dikirim. Pengirim menerima HTTP 200 atau 202 beserta ID transaksi.
Proses lanjutan berjalan. n8n menghubungi payment gateway, membuat invoice, dan mengirim notifikasi.
Status diperbarui. Pesanan berubah menjadi paid, failed, atau needs_review.

Responsnya tidak perlu rumit. Contohnya:

{
  "accepted": true,
  "request_id": "ord-2026-0148",
  "status": "processing"
}

Perhatikan bahwa respons tersebut tidak mengklaim pembayaran sudah berhasil. Ia hanya menyatakan bahwa permintaan sudah diterima dan sedang diproses. Ini perbedaan kecil dalam teks, tetapi sangat penting untuk mencegah ekspektasi yang salah.

Memilih pola respons di n8n

1. Gunakan “Immediately” untuk pekerjaan di belakang layar

Jika pengirim hanya membutuhkan tanda terima, atur Webhook node agar merespons segera. Dokumentasi n8n menjelaskan bahwa mode ini mengembalikan pesan bahwa workflow sudah dimulai, tanpa menunggu seluruh workflow selesai. ([docs.n8n.io](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/))

Pola ini cocok untuk notifikasi masuk, sinkronisasi data, pencatatan lead, atau antrean pekerjaan yang tidak perlu langsung menghasilkan jawaban final.

2. Gunakan “Respond to Webhook” untuk kontrol yang lebih jelas

Jika respons harus dikirim setelah data disimpan atau setelah pemeriksaan tertentu, pilih Using 'Respond to Webhook' Node. Letakkan node tersebut setelah langkah yang ingin dijadikan batas minimal keberhasilan.

Misalnya, webhook tidak boleh menjawab “diterima” sebelum ID transaksi berhasil disimpan. Jika penyimpanan gagal, workflow sebaiknya mengembalikan respons error atau mengarahkan masalah ke jalur penanganan khusus.

Perlu diperhatikan, Respond to Webhook bekerja menggunakan item data pertama yang masuk. Jika workflow menghasilkan banyak item, gabungkan dahulu datanya atau gunakan opsi untuk mengembalikan semua item sesuai kebutuhan. ([docs.n8n.io](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.respondtowebhook/))

Bagaimana melanjutkan proses setelah respons dikirim?

Ada dua pola yang umum.

Pola pertama: satu workflow, respons dikirim di tengah. Workflow mengirim respons melalui Respond to Webhook, lalu node-node berikutnya melanjutkan proses. Ini mudah dibuat dan cukup untuk pekerjaan yang tidak terlalu panjang.

Namun, jangan menganggap pengiriman respons otomatis membuat semua proses setelahnya kebal terhadap masalah. Jika instance berhenti, kredensial kedaluwarsa, atau API eksternal gagal, langkah berikutnya tetap bisa berhenti. Karena itu, proses penting sebaiknya memiliki pencatatan status, retry yang terukur, dan notifikasi ketika gagal.

Pola kedua: pisahkan penerima dan pekerja. Workflow pertama menerima webhook lalu menyimpan pekerjaan ke database, tabel, atau sistem antrean. Workflow kedua mengambil pekerjaan tersebut berdasarkan jadwal atau trigger tertentu. Pola ini lebih mudah dipantau ketika volume meningkat, meskipun membutuhkan komponen tambahan.

Kapan memakai Wait node?

Jika workflow memang harus berhenti dan menunggu kejadian tertentu, gunakan Wait node. Node ini dapat menjeda eksekusi dan menyimpan data eksekusi ke database. Workflow kemudian dilanjutkan ketika waktu yang ditentukan tercapai, form dikirim, atau webhook pemulihan dipanggil. ([docs.n8n.io](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.wait/))

Contohnya adalah alur persetujuan invoice. n8n membuat URL resume yang unik untuk eksekusi tersebut, lalu URL itu dikirim kepada sistem atau pengguna yang akan memberikan keputusan. Setelah callback diterima, workflow melanjutkan langkah berikutnya.

Jangan memakai Wait sebagai pengganti antrean untuk setiap pekerjaan. Untuk ribuan tugas yang menunggu, desain penyimpanan status dan mekanisme pemrosesan perlu dipikirkan lebih serius agar tidak sulit dirawat.

Hal yang sering dilupakan

Gunakan status yang jelas. Bedakan received, processing, success, dan failed.
Simpan request ID. ID ini membantu pencarian log dan mencegah permintaan yang sama diproses tanpa sengaja.
Siapkan idempotensi. Jika pengirim mengulang webhook, workflow harus bisa mengenali bahwa transaksi tersebut sudah pernah diterima.
Amankan endpoint. n8n mendukung Basic auth, Header auth, JWT auth, dan pembatasan alamat IP untuk Webhook node. Jangan membiarkan endpoint sensitif terbuka tanpa perlindungan. ([docs.n8n.io](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/))
Jangan mengirim rahasia dalam respons. Respons webhook bisa tercatat di log aplikasi, proxy, atau sistem pemantauan.
Periksa eksekusi yang gagal. n8n menyediakan daftar eksekusi dan kemampuan untuk mencoba kembali workflow yang gagal, sehingga proses pemulihan tidak harus dilakukan dari nol. ([docs.n8n.io](https://docs.n8n.io/workflows/executions/all-executions/?utm_source=openai))

Yang bisa dilakukan sekarang

Ambil satu workflow yang saat ini membuat aplikasi pengirim menunggu lama. Catat berapa langkah yang benar-benar diperlukan sebelum respons awal dikirim. Biasanya, hanya tiga hal yang wajib dilakukan di depan: memeriksa autentikasi, memvalidasi format dasar, dan menyimpan permintaan.

Setelah itu, kirim respons yang jujur: apakah permintaan diterima, sedang diproses, atau ditolak. Pindahkan pekerjaan berat ke tahap berikutnya, lalu tambahkan pencatatan status dan notifikasi kegagalan.

Workflow yang baik bukan yang selalu menyelesaikan semuanya dalam satu tarikan napas, melainkan yang tahu kapan harus menjawab, kapan harus menunggu, dan bagaimana melaporkan jika sesuatu gagal.

Pola asynchronous tidak menghilangkan risiko. Ia hanya menempatkan risiko di lokasi yang lebih mudah dikelola. Pengguna mendapatkan respons lebih cepat, sementara tim tetap memiliki ruang untuk memproses pekerjaan yang lebih panjang tanpa membuat seluruh sistem ikut menunggu.

Sumber & bacaan lebih lanjut

– Rio Yotto @rioyotto