Banyak workflow n8n dimulai dari pertanyaan sederhana: kapan proses ini harus berjalan? Jawabannya sering jatuh ke dua pilihan, yaitu webhook atau polling. Keduanya sama-sama bisa memulai workflow, tetapi cara kerja dan konsekuensinya berbeda.
Webhook menunggu layanan lain mengirimkan data ketika sebuah peristiwa terjadi. Polling bekerja seperti petugas yang memeriksa kotak surat secara berkala: setiap beberapa menit, workflow bertanya apakah ada data baru. Perbedaan kecil ini bisa berpengaruh besar ketika workflow mulai menangani order, formulir pelanggan, notifikasi WhatsApp, sinkronisasi stok, atau pembaruan dari API.
Webhook: cepat karena tidak perlu menebak
Webhook adalah URL yang disediakan n8n untuk menerima permintaan dari aplikasi atau layanan lain. Ketika event terjadi—misalnya formulir dikirim atau pembayaran berhasil—layanan tersebut mengirim data ke URL itu dan workflow langsung dimulai. Dokumentasi n8n menjelaskan bahwa Webhook node juga dapat digunakan untuk menerima data dari layanan yang tidak memiliki trigger khusus. Lihat dokumentasi Webhook n8n.
Keunggulan utamanya adalah latensi rendah. Anda tidak perlu menunggu jadwal pemeriksaan berikutnya. Jika sistem pengirim mengirim event pada pukul 10.01, workflow dapat mulai diproses hampir saat itu juga.
Contoh sederhananya:
- Pelanggan mengisi formulir.
- Aplikasi formulir mengirim data ke Webhook n8n.
- n8n memvalidasi nomor telepon dan isi permintaan.
- n8n menyimpan data ke CRM dan mengirim notifikasi ke tim.
Namun, webhook bukan berarti otomatis lebih baik. Anda perlu memastikan layanan pengirim mendukung webhook, URL dapat diakses dari internet, dan endpoint tersebut cukup aman. n8n menyediakan opsi autentikasi seperti Basic auth, Header auth, dan JWT auth, serta pembatasan IP untuk webhook. Jangan membiarkan endpoint penting tanpa perlindungan hanya karena URL-nya terlihat panjang dan acak.
Polling: lebih sederhana, tetapi ada jeda
Polling digunakan ketika layanan yang ingin dipantau tidak menyediakan webhook, atau ketika Anda memang tidak membutuhkan respons seketika. Workflow dijalankan sesuai jadwal untuk memeriksa apakah ada data baru.
Di n8n, Schedule Trigger dapat menjalankan workflow pada interval tertentu, dari detik, menit, jam, hari, hingga jadwal berbasis Cron. RSS Feed Trigger juga menggunakan pola polling untuk memeriksa feed pada waktu yang ditentukan. Dokumentasi Schedule Trigger dan dokumentasi RSS Feed Trigger menjelaskan pilihan jadwal tersebut.
Polling cocok untuk kasus seperti:
- Memeriksa API vendor setiap 15 menit.
- Mengambil data penjualan dari sistem lama yang tidak mendukung webhook.
- Mengecek RSS beberapa kali sehari.
- Menyamakan data dari dua sistem yang hanya menyediakan endpoint untuk membaca data.
Kelemahannya adalah jeda dan pekerjaan berulang. Jika workflow berjalan setiap lima menit, data baru bisa menunggu hingga hampir lima menit sebelum diproses. Jika interval dibuat terlalu rapat, jumlah request meningkat dan layanan yang dipanggil mungkin mengenakan batas penggunaan atau menolak request.
Pilih berdasarkan kemampuan sistem, bukan tren
Gunakan webhook jika tiga kondisi ini terpenuhi: layanan pengirim mendukung webhook, Anda membutuhkan respons cepat, dan endpoint bisa diamankan dengan baik. Contohnya adalah notifikasi pembayaran, event dari aplikasi internal, atau pesan masuk yang perlu segera diteruskan ke tim.
Gunakan polling jika layanan tidak menyediakan webhook, data tidak harus real-time, atau Anda ingin mengendalikan kapan dan seberapa sering sinkronisasi dilakukan. Untuk laporan harian, pembaruan katalog, dan pengecekan RSS, polling biasanya sudah memadai.
Ada pula pendekatan campuran. Webhook bisa digunakan untuk menerima sinyal awal, sementara polling dipakai sebagai pemeriksaan cadangan. Misalnya, layanan pembayaran mengirim webhook ketika transaksi berubah, lalu workflow terjadwal memeriksa transaksi yang belum berstatus final setiap satu jam. Ini bukan berarti semua data diproses dua kali. Kuncinya adalah menyimpan ID event atau ID transaksi dan memeriksa apakah data tersebut sudah pernah ditangani.
Hal yang sering dilupakan saat memakai webhook
Bedakan URL pengujian dan produksi
n8n memiliki URL webhook untuk pengujian dan produksi. URL pengujian digunakan saat Anda menekan Listen for Test Event, sedangkan URL produksi terdaftar ketika workflow dipublikasikan. Data dari URL produksi dapat dilihat melalui riwayat eksekusi, bukan langsung di editor. Kesalahan memakai URL pengujian sering membuat pengguna mengira integrasi sudah aktif, padahal workflow belum benar-benar menerima event produksi.
Balas cepat jika prosesnya panjang
Jika webhook harus memanggil beberapa API, membuat file, atau mengirim pesan ke banyak tujuan, jangan selalu membuat pengirim menunggu sampai seluruh proses selesai. Webhook node n8n mendukung respons segera maupun respons setelah node terakhir selesai. Untuk proses panjang, respons segera biasanya lebih aman agar layanan pengirim tidak menganggap request gagal karena terlalu lama.
Validasi isi request
Jangan langsung mempercayai semua data yang masuk. Periksa token, tipe event, ID transaksi, dan field wajib sebelum menjalankan tindakan penting. Data yang tidak sesuai dapat diarahkan ke jalur penolakan atau dicatat untuk pemeriksaan manual.
Hal yang perlu diperhatikan saat memakai polling
Tentukan penanda data baru
Polling tanpa penanda akan mudah memproses data lama berulang kali. Gunakan timestamp, nomor urut, ID terakhir, atau status sinkronisasi. Simpan penanda tersebut di database, Data Table, atau penyimpanan yang sesuai—bukan hanya di memori workflow.
Atur interval berdasarkan kebutuhan
Jangan memilih interval satu menit hanya karena bisa. Tanyakan berapa cepat data benar-benar perlu diproses. Jika pelanggan masih bisa menunggu 15 menit, interval 15 menit mungkin lebih masuk akal dan lebih hemat request.
Perhatikan zona waktu dan workflow yang terlewat
Jadwal n8n bergantung pada zona waktu workflow atau instance. Workflow juga harus dipublikasikan agar pemicu jadwal berjalan. Untuk proses penting, tentukan apa yang terjadi jika instance sempat mati: apakah data yang terlewat boleh diambil belakangan, atau cukup diproses pada jadwal berikutnya?
Apa artinya bagi kita?
Webhook bukan versi “lebih canggih” dari polling, dan polling bukan solusi kelas dua. Webhook unggul dalam kecepatan, sementara polling unggul dalam kompatibilitas dan kendali jadwal. Pilihan yang baik adalah pilihan yang sesuai dengan kemampuan layanan sumber dan tingkat urgensi proses.
Sebelum membuat workflow, tulis tiga hal: seberapa cepat data harus diproses, apakah sistem sumber mendukung webhook, dan bagaimana mencegah data diproses ulang. Tiga pertanyaan ini biasanya lebih berguna daripada langsung memilih node pertama yang terlihat paling praktis.
Yang bisa dilakukan sekarang
- Periksa dokumentasi API layanan yang ingin dihubungkan.
- Jika tersedia webhook, buat workflow kecil yang hanya mencatat payload untuk pengujian.
- Jika harus polling, mulai dari interval longgar seperti 15 atau 30 menit.
- Simpan ID atau timestamp data terakhir yang berhasil diproses.
- Tambahkan autentikasi, validasi, dan notifikasi ketika workflow gagal.
Dengan pola ini, n8n tidak sekadar menjalankan tugas otomatis. Ia menjadi sistem yang tahu kapan harus bereaksi, kapan cukup memeriksa, dan kapan perlu berhenti agar tidak membuat masalah baru.
Sumber & bacaan lebih lanjut
– Rio Yotto @rioyotto