Webhook

Webhook คือกลไกที่ให้ระบบต้นทางยิงข้อมูลเข้ามาที่ URL ซึ่งเราเปิดค้างรอไว้ ทันทีที่มีเหตุการณ์ที่เราสนใจเกิดขึ้น เอกสาร About webhooks ของ GitHub อธิบายกลไกนี้ไว้ว่า webhook ทำให้เราสมัครรับเหตุการณ์ที่เกิดขึ้นในระบบซอฟต์แวร์ แล้วได้รับข้อมูลส่งมาที่เซิร์ฟเวอร์ของเราโดยอัตโนมัติทุกครั้งที่เหตุการณ์เหล่านั้นเกิดขึ้น หน้าเดียวกันเขียนเทียบกับอีกวิธีไว้ตรงๆ ว่า webhook ถูกใช้เพื่อรับข้อมูลในจังหวะที่มันเกิดขึ้นจริง ตรงข้ามกับการ poll api ซึ่งหมายถึงการเรียก API เป็นระยะเพื่อดูว่ามีข้อมูลให้แล้วหรือยัง และสรุปความต่างของภาระงานไว้ว่าเมื่อใช้ webhook เราต้องแสดงความสนใจในเหตุการณ์หนึ่งเพียงครั้งเดียวคือตอนที่สร้าง webhook นั้น เอกสารฉบับเดียวกันยังระบุว่า webhook ใช้แรงและใช้ทรัพยากรน้อยกว่าการ poll API

ในทางปฏิบัติ webhook มีสองฝั่ง ฝั่งที่ยิงคือระบบต้นทางซึ่งรู้ก่อนใครว่าเหตุการณ์เกิดขึ้นแล้ว ส่วนฝั่งที่รับคือ URL ที่เราเตรียมไว้ให้เขายิงเข้ามา เอกสารของ n8n ระบุว่า Webhook node ใช้สร้าง webhook ที่รับข้อมูลจากแอปและบริการต่างๆ เมื่อมีเหตุการณ์เกิดขึ้น และเป็น trigger node ซึ่งหมายความว่ามันเริ่มต้น workflow ของ n8n ได้ node ตัวนี้รองรับ HTTP request method มาตรฐานคือ DELETE, GET, HEAD, PATCH, POST และ PUT จุดที่คนต่อ n8n สะดุดกันบ่อยคือเรื่อง URL สองเส้น เพราะเอกสารเขียนไว้ว่า n8n จะลงทะเบียน test webhook เมื่อเราเลือก Listen for Test Event หรือเมื่อเราสั่ง Execute workflow ในกรณีที่ workflow นั้นยังไม่ได้ถูกเปิดใช้งาน และจะลงทะเบียน production webhook เมื่อเรา publish workflow นอกจากนี้ยังตั้งได้ว่าจะให้ตอบกลับต้นทางอย่างไร โหมด Immediately จะคืนรหัสสถานะพร้อมข้อความ Workflow got started โหมด When Last Node Finishes จะคืนรหัสสถานะพร้อมข้อมูลที่ออกจาก node สุดท้ายที่ทำงานใน workflow และยังมีโหมด Using Respond to Webhook Node ที่ให้เรากำหนดคำตอบเองผ่าน node ชื่อ Respond to Webhook กับโหมด Streaming response ที่เอกสารระบุว่าเปิดให้ส่งข้อมูลกลับไปหาผู้เรียกแบบเรียลไทม์ระหว่างที่ workflow ยังทำงานอยู่ โดยเอกสารกำกับเงื่อนไขไว้ด้วยว่าโหมดนี้ต้องมี node ที่รองรับการ stream อยู่ใน workflow เอกสารยังระบุเพดานไว้ว่าขนาด payload สูงสุดของ webhook คือ 16MB ซึ่งถ้าเรา self-host n8n เอง ปรับค่านี้ได้ผ่าน environment variable ชื่อ N8N_PAYLOAD_SIZE_MAX ฝั่ง power-automate ใช้ทริกเกอร์ชื่อ When an HTTP request is received ซึ่งเอกสารฝึกอบรมของ Microsoft ฉบับปรับปรุงมิถุนายน 2025 ระบุว่าเมื่อใช้เป็นทริกเกอร์ connector ตัวนี้จะสร้าง URL ให้อัตโนมัติ โดย URL นั้นใช้กับ method POST ได้ และเขียนกำกับไว้ว่า URL จะถูกสร้างขึ้นหลังจากบันทึกแล้ว หน้าเดียวกันยังระบุว่าทริกเกอร์ HTTP นี้กำหนดได้ด้วยว่าใครสั่งให้ flow ทำงานได้ โดยมีสามตัวเลือกคือผู้ใช้คนใดก็ได้ใน tenant ของเรา ผู้ใช้ที่ระบุเจาะจงใน tenant ของเรา และใครก็ได้

เหตุผลที่คนทำงานควรรู้จักคำนี้คือ webhook เป็นกาวที่ทำให้ผลลัพธ์ของงาน workflow-automation และของ agent ไปโผล่ในระบบที่ทีมใช้จริง แทนที่จะค้างอยู่ในเครื่องมือที่ต้องเปิดเข้าไปดูเอง ตัวอย่างที่เห็นภาพชัดคือแชตบอตขององค์กร เอกสารของ LINE ระบุว่า webhook URL คือ endpoint ของ bot server ที่ LINE Platform ส่ง webhook payload ไปให้ และอธิบายจังหวะที่มันยิงไว้ว่าเมื่อผู้ใช้เพิ่มบัญชีทางการของเราเป็นเพื่อนหรือส่งข้อความมาที่บัญชีนั้น LINE Platform จะส่ง HTTP POST request มาที่ bot server ของเรา โดยคำขอนั้นมี webhook event object อยู่ข้างในพร้อมกับ signature ที่ส่วนหัว ข้อควรระวังคือ URL ที่เปิดรับ webhook เป็นประตูที่หันออกอินเทอร์เน็ต จึงต้องคิดเรื่องความปลอดภัยตั้งแต่วันแรก เอกสารของ LINE กำหนดเงื่อนไขไว้ชัดว่า webhook URL ต้องใช้ HTTPS และมีใบรับรอง SSL/TLS ที่ออกโดย certificate authority ซึ่งเบราว์เซอร์ทั่วไปเชื่อถืออย่างกว้างขวาง และเขียนต่อว่าใบรับรองที่เซ็นเองไม่ได้รับอนุญาต ฝั่ง n8n ก็เขียนไว้ว่าเราบังคับให้บริการใดก็ตามที่เรียก webhook URL ของเราต้องยืนยันตัวตนก่อนได้ โดยเลือกได้จาก Basic auth, Header auth, JWT auth หรือไม่ใช้เลย ซึ่งแปลว่าการปล่อยให้ไม่มีการยืนยันตัวตนเลยก็เป็นตัวเลือกหนึ่งที่เลือกได้ ความปลอดภัยตรงนี้จึงเป็นสิ่งที่เราต้องตัดสินใจเอง ไม่ใช่สิ่งที่ระบบจัดการให้ ถ้าเลือกใช้แบบ Header auth ก็ต้องดูแลค่าลับนั้นแบบเดียวกับที่ดูแล api-key อีกเรื่องที่ควรชั่งน้ำหนักคือไม่ใช่ทุกงานที่คุ้มกับการตั้ง webhook เอกสารของ GitHub เขียนกรณีกลับด้านไว้ว่าถ้าเราต้องการข้อมูลแค่ครั้งเดียวหรือเป็นครั้งคราว หรือต้องการดึงข้อมูลจากทรัพยากรกลุ่มเล็กๆ โดยไม่มีแผนจะขยาย เราจะเรียก API เอาตอนที่ต้องการก็ได้ แต่ถ้างานนั้นต้องรู้เร็วและเกิดถี่ การไล่ถามซ้ำๆ จะกินทรัพยากรมากกว่าและมีโอกาสไปชน rate-limit ของต้นทางเข้าสักวัน

ตัวอย่างจากบทสนทนาจริง

หัวหน้าฝ่ายบริการลูกค้า: ตอนนี้ระบบสรุปเคสด้วย AI ทำงานดีนะคะ แต่ทีมต้องเข้าไปกดเปิดดูในเครื่องมือเองทุกเช้า พอจะให้สรุปมันเด้งเข้ากลุ่มแชตทันทีที่ปิดเคสได้ไหม

ทีม automation: ได้ครับ ต้องขอให้ระบบ ticket ยิง webhook มาที่ flow ของเราตอนสถานะเปลี่ยนเป็นปิดเคส แล้วเราค่อยส่งต่อเข้ากลุ่มให้ ถ้าเขาไม่มี webhook ให้ เราต้องตั้งให้ไปไล่ถามระบบเขาทุกๆ ห้านาทีแทน ซึ่งช้ากว่าและเปลืองโควตาเรียกทั้งวันโดยที่ส่วนใหญ่ถามไปก็ไม่มีอะไรใหม่

ฝ่ายบัญชี: flow ที่ลองเมื่อวานมันทำงานตอนเรากดทดสอบนะ แต่พอวันนี้ระบบเขายิงเข้ามาจริงกลับเงียบสนิท

ทีม automation: URL ที่ส่งให้เขาไปเป็นเส้นสำหรับทดสอบครับ n8n แยก URL ทดสอบกับ URL ที่ใช้จริงออกจากกัน เส้นทดสอบจะถูกลงทะเบียนตอนเรากด Listen for Test Event ส่วนเส้นที่ใช้จริงจะถูกลงทะเบียนตอนเรา publish workflow เดี๋ยวผมส่งเส้นที่ถูกให้ใหม่

ฝ่าย IT: ก่อนจะเปิด URL นี้ออกอินเทอร์เน็ต ขอสองอย่างนะครับ ต้องเป็น https และต้องมีการยืนยันตัวตนที่ header ด้วย

ทีม automation: เข้าใจครับ ฝั่ง LINE เขาบังคับ https กับใบรับรองที่ CA ออกให้อยู่แล้ว ส่วนตัว flow ผมจะเปิด Header auth แล้วเก็บค่าลับไว้ที่เดียวกับกุญแจตัวอื่น ไม่แปะไว้ในเอกสารทีม

ระวังสับสนกับ

• api : ทิศทางของการเรียกต่างกัน การใช้ API ตามปกติคือเราเป็นฝ่ายยิงคำขอไปถามเขาเมื่อเราอยากรู้ ส่วน webhook คือเขาเป็นฝ่ายยิงข้อมูลมาหาเราเองเมื่อมีเหตุการณ์เกิดขึ้น ทั้งสองอย่างวิ่งบน HTTP เหมือนกันและมักถูกใช้คู่กัน เช่น รับ webhook เข้ามาแล้วค่อยเรียก API กลับไปขอรายละเอียดเพิ่ม
• mcp : MCP เป็นมาตรฐานสำหรับต่อ AI เข้ากับเครื่องมือและข้อมูล เพื่อให้โมเดลเรียกใช้ความสามารถเหล่านั้นได้ ส่วน webhook เป็นท่อแจ้งเหตุการณ์ทั่วไปที่มีมาก่อนยุค AI และไม่ได้ผูกกับ AI โดยตรง ระบบที่ไม่มี AI เลยก็ใช้ webhook กันเป็นปกติ
• connector : connector คือของสำเร็จรูปที่ผู้ให้บริการทำมาให้เชื่อมสองระบบเข้าหากันโดยไม่ต้องเขียนตัวเชื่อมเอง ข้างในหลายตัวก็ใช้ webhook เป็นกลไกอยู่แล้ว ต่างกันตรงที่ webhook เป็นชิ้นส่วนดิบที่เราหยิบมาต่อเองได้ ตราบใดที่ระบบต้นทางเปิดให้ยิง webhook ออกมา ส่วน connector ครอบคลุมเฉพาะกรณีที่เจ้าของทำมาให้