Respons dan ralat webhook: bagaimana ia berfungsi dalam AI Flowi Workflow?

Respons dan ralat webhook: pilih mod respons bagi setiap kaedah Universal Webhook yang diterima. Gunakan From Flow dan komponen Webhook Response apabila aliran kerja perlu menetapkan status dan badan HTTP. Resipi webhook ke Google Sheets yang diuji mengembalikan 200 selepas penulisan yang sah, 422 bagi input tidak sah dan 403 bagi kunci API yang tiada atau tidak sah. Kegagalan Google Sheets di hiliran menghentikan aliran dan mengembalikan ralat platform mentah dalam versi 1.9.2; ia tidak mencapai cabang respons tersuai.

Diterbitkan 9 Oktober 2026 · Dikemas kini 9 Oktober 2026. Bukti produksi: 8–9 Oktober 2026, AI Flowi Workflow 1.9.2.

Oleh Ai Flowi · Semakan teknikal: Janice Lee, Sokongan Teknikal, Ai Flowi.

Ikuti resipi webhook ke Google Sheets dan keputusan ujian produksinya. Gunakan versi perlindungan pendua apabila penghantar mencuba semula penghantaran.

Mod respons manakah yang patut saya gunakan?

Tetapkan mod respons secara berasingan bagi setiap kaedah HTTP yang diaktifkan dalam Universal Webhook.

Bagi From Flow, tepat satu Webhook Response mesti terpakai kepada laluan yang dilaksanakan. Resipi yang diuji mempunyai respons kejayaan dan penolakan berasingan yang disambungkan kepada cabang Verification Router yang berbeza. Ketiadaan respons atau beberapa respons yang terpakai boleh menghasilkan ralat.

Test Endpoint merekodkan permintaan tanpa melaksanakan aliran. Ia tidak boleh menunjukkan balasan From Flow yang lengkap. Uji keseluruhan permintaan, penulisan dan respons melalui Production Endpoint menggunakan data sintetik.

Bagaimanakah saya menetapkan status dan badan HTTP?

Pilih From Flow bagi kaedah webhook, kemudian sambungkan output cabang kepada Webhook Response.

Badan dalam Response Definition mengatasi Response Body yang disambungkan; status dan jenis kandungannya mengatasi medan konfigurasi yang sepadan. Bagi nama pengepala yang berulang, Additional Response Headers yang dikonfigurasikan diutamakan berbanding pengepala dalam Response Definition.

Apakah yang ditunjukkan oleh ujian 200, 422 dan 403?

Keputusan ini adalah untuk resipi webhook ke Google Sheets yang telah disahkan dan tidak menggunakan model, dengan POST, pengesahan Platform API Key dan mod From Flow. Ia diuji dalam produksi pada 8 Oktober 2026, kemudian diimport ke aliran baharu dan diuji semula. Versi perlindungan pendua mengulangi semakan ini pada 9 Oktober 2026, pada aliran asal dan salinan yang diimport.

Contohnya, ujian e-mel yang tiada mengembalikan HTTP 422 dengan badan pengesahan input ini:

{"verified":false,"error":"Validation failed","details":["email is required and must be a valid address"]}

Status ini bergantung pada konfigurasi yang diuji. Ia bukan jaminan bahawa setiap aliran kerja menggunakan pengesahan input atau balasan yang sama. Pengesahan External Provider tidak diuji.

Apakah yang berlaku jika komponen hiliran gagal?

Batasan mengikut tarikh: AI Flowi Workflow 1.9.2, direkodkan 8–9 Oktober 2026. Ralat Google Sheets menghentikan graf sebelum Webhook Response di hiliran berjalan. Komponen Sheets tidak mempunyai output ralat untuk cabang ralat dalam aliran pada versi ini, dan templat respons From Flow diabaikan selepas kegagalan.

Spreadsheet ID yang tidak wujud mengembalikan HTTP 404 dengan ralat komponen mentah dalam ujian Append Rows pada 8 Oktober. Ujian Upsert Row pada 9 Oktober mengembalikan tingkah laku 404 mentah yang sama pada aliran asal dan aliran yang diimport. Bilangan baris helaian ujian kekal tidak berubah. Respons 502 terkawal yang dihasratkan tidak dicapai.

HTTP 500 turut diperhatikan apabila pertanyaan JQ yang tersembunyi digugurkan semasa pelaksanaan, dengan JSON Query is required and cannot be blank. Pastikan medan JQ Expression kelihatan. Pengendalian platform yang direkodkan memetakan teks ralat yang mengandungi “not found” kepada 404; kegagalan lain boleh mengembalikan 500 dengan butiran ralat mentah. Jangan tafsirkan 404 di sini sebagai bukti bahawa URL webhook itu sendiri tiada.

Menambahkan Webhook Response selepas nod Sheets tidak boleh menangkap kegagalan ini. Balasan terkawal bagi kegagalan hamparan memerlukan perubahan pada platform, seperti output ralat pada komponen Google atau penapisan maklumat sensitif daripada ralat webhook.

Bagaimanakah saya mengelakkan pendedahan ralat mentah kepada pengguna akhir?

Jangan paparkan respons titik akhir secara verbatim kepada pengguna akhir. Ralat Sheets yang direkodkan mengandungi URL API Google dan Spreadsheet ID. Sahkan sambungan Google, Spreadsheet ID dan perkongsian sebelum mula digunakan dalam produksi; pastikan aplikasi yang menerima balasan memaparkan mesej terkawal kepada pengguna apabila permintaan gagal.

Resipi perlindungan pendua memetakan hasil Sheets yang berjaya kepada {"status":"inserted"} atau {"status":"duplicate"}, lalu membuang Spreadsheet ID, julat dan medan Google daripada badan kejayaan tersebut. Pemetaan ini tidak menapis maklumat sensitif daripada kegagalan komponen kerana ia tidak pernah berjalan selepas ralat Sheets.

Bagaimanakah saya patut mereka bentuk untuk percubaan semula penghantar?

Gunakan versi perlindungan pendua yang diuji apabila penghantar mencuba semula. Resipi Append Rows yang lebih ringkas menambahkan satu lagi baris bagi penghantaran kedua yang sama. Versi 9 Oktober menggunakan Upsert Row dengan event_id sebagai kunci: hantar pengecam yang sama untuk percubaan semula peristiwa yang sama dan pengecam berbeza untuk peristiwa baharu.

Permintaan sintetik yang telah dibersihkan daripada maklumat sensitif untuk versi perlindungan pendua:

{
  "event_id": "example-event-001",
  "name": "Webhook Test",
  "email": "test@example.com",
  "request": "Synthetic test"
}

• Penghantaran berturutan: permintaan pertama memasukkan satu baris dan mengembalikan 200 {"status":"inserted"}. Pengecam yang berulang mengemas kini baris tersebut, mengembalikan 200 {"status":"duplicate"} dan tidak menambahkan baris kedua. Kemas kini mengutamakan penulisan terakhir.
• Pengecam: teks yang dibekalkan oleh pemanggil, 1–100 aksara, disimpan secara verbatim; padanan peka huruf besar dan kecil serta tidak membuang ruang kosong di hujung atau pangkal.
• Skop dan tempoh penyimpanan: satu lembaran kerja dalam satu hamparan; semua penghantar yang menulis di situ berkongsi ruang kunci. Perlindungan kekal selagi baris menyimpan pengecam tersebut. Tiada tamat tempoh atau log penerimaan berasingan; memadam atau mengedit pengecam membolehkan satu lagi pemasukan.
• Pendua serentak yang diukur: Pada 9 Oktober 2026, lima penghantaran serentak dengan satu event_id semuanya mengembalikan 200 dan menulis 3 baris tambahan pada helaian (15 → 18; baris peristiwa yang sepadan 0 → 3). Aliran kerja ini tidak selamat untuk pelaksanaan serentak. Pastikan penghantar membuat penghantaran secara berturutan atau singkirkan pendua di hiliran. Upsert Row membaca dan menulis tanpa penguncian. Baris pendua sedia ada tidak digabungkan. Lihat keputusan ujian semula kebolehpercayaan.

Perlindungan pendua berturutan dan pengendalian kegagalan hamparan mentah ialah dua perkara berasingan. Versi percubaan semula yang diuji masih mempunyai batasan kegagalan versi 1.9.2 di atas.

Apakah yang patut saya uji sebelum mula digunakan dalam produksi?

1. Konfigurasi: aktifkan kaedah HTTP penghantar, konfigurasikan pengesahan dan pilih mod respons. Dalam From Flow, semak bahawa tepat satu respons terpakai kepada setiap laluan yang dilaksanakan. Pastikan medan JQ Expression kelihatan.
2. Penulisan berjaya: hantar input sintetik yang sah ke Production Endpoint. Semak HTTP 200, badan dan satu baris baharu bagi peristiwa baharu.
3. Pengesahan input: tinggalkan e-mel, gunakan nama berbentuk nombor, bekalkan e-mel tidak sah dan hantar JSON yang salah format. Dalam resipi yang diuji, setiap satu mengembalikan 422 tanpa menambahkan baris.
4. Pengesahan identiti: uji Platform API Key yang tiada dan yang tidak sah. Setiap satu patut mengembalikan 403 tanpa menambahkan baris dalam persediaan yang diuji.
5. Percubaan semula: ulang event_id yang sama secara berturutan. Semak inserted diikuti duplicate, dengan jumlah satu baris. Hantar event_id yang berbeza dengan badan yang sama dan semak bahawa ia menambahkan baris berasingan. Kelompok lima penghantaran serentak pada 9 Oktober 2026 mengembalikan 200 bagi semua permintaan dan menambahkan 3 baris bagi satu event_id. Pastikan penghantar membuat penghantaran secara berturutan atau singkirkan pendua di hiliran.
6. Had pengecam: dalam versi perlindungan pendua, nilai event_id yang tiada, null, berbentuk nombor, kosong dan sepanjang 101 aksara patut mengembalikan 422 tanpa baris; pengecam sah sepanjang 100 aksara patut mengembalikan 200 dan menambahkan satu baris.
7. Kegagalan hiliran: gunakan aliran ujian sintetik berasingan dengan Spreadsheet ID yang tidak wujud. Rekodkan status dan badan HTTP sebenar serta baca semula bilangan baris helaian ujian. Versi 1.9.2 mengembalikan ralat 404 mentah; sahkan tingkah laku versi yang anda gunakan dan semak mesej kegagalan yang dipaparkan kepada pengguna oleh aplikasi.
8. Salinan yang diimport: selepas mengimport aliran kerja yang telah dibersihkan daripada maklumat sensitif, tetapkan akaun Google, Spreadsheet ID dan pengesahan webhook anda, kemudian ulang semakan.

Baca gambaran keseluruhan produk AI Flowi Workflow dan sahkan tingkah laku kegagalan yang anda perlukan sebelum memilih konfigurasi.

Dokumentasi berkaitan

Universal Webhook · Webhook Response · Resipi webhook ke Google Sheets · Keputusan ujian produksi · Persediaan dan batasan perlindungan pendua