เชื่อมต่อ API เว็บไซต์แบรนด์ตัวเอง: REST API, Webhook และวิธีเชื่อมต่อกับระบบอื่น
1. WordPress REST API: ทำความเข้าใจความสามารถพื้นฐานก่อน
WordPress มี REST API ในตัวตั้งแต่เวอร์ชัน 4.7 ไม่ต้องติดตั้งปลั๊กอินก็ใช้ได้ รูปแบบ endpoint คือ https://โดเมนของคุณ/wp-json/wp/v2/posts เปิดในเบราว์เซอร์ก็เห็นรายการบทความในรูปแบบ JSON ได้เลย API นี้เปิดเป็นสาธารณะโดยค่าเริ่มต้น ใครก็อ่านบทความ หน้าเว็บ และคลังสื่อของคุณได้ ซึ่งเป็นทั้งข้อดี (เชื่อมต่อง่าย) และความเสี่ยง (ข้อมูลภายในรั่วไหล)
การเขียนข้อมูล (สร้างบทความใหม่ แก้ไขคำสั่งซื้อ เพิ่มผู้ใช้) ต้องยืนยันตัวตน WordPress รองรับ 2 วิธี: Application Passwords (ง่าย สร้างในหน้าข้อมูลผู้ใช้ เหมาะกับการเรียกจากเซิร์ฟเวอร์ของคุณเอง) และ OAuth 2.0 (ซับซ้อน เหมาะกับการอนุญาตแอปของบุคคลที่สาม) การเชื่อมต่อเว็บไซต์แบรนด์ตัวเองกับ CRM ของตัวเองใช้ Application Passwords ก็เพียงพอ อย่าเห็นแก่ง่ายแล้ว hardcode ชื่อผู้ใช้และรหัสผ่าน admin ไว้ในโค้ด
กรอบการตัดสินใจ: คุณต้องอ่านหรือเขียนข้อมูลจาก WordPress? อ่านอย่างเดียว (ดึงรายการบทความ ประวัติคำสั่งซื้อ) ใช้คำขอ GET พร้อม Application Passwords ก็พอ เขียน (สร้างคำสั่งซื้อ อัปเดตผู้ใช้ ส่ง Webhook) ต้องใช้คำขอ POST/PUT และกำหนดสิทธิ์ให้น้อยที่สุด เช่น ให้แค่สิทธิ์ “แก้ไขคำสั่งซื้อ” ไม่ให้สิทธิ์ “จัดการการตั้งค่าทั้งหมด” จะประกอบ tech stack อย่างไร ดูที่เทคโนโลยีสแตกของ crater。
| Endpoint | วิธีการ | ใช้ทำอะไร | ข้อกำหนดการรับรอง |
|---|---|---|---|
| /wp-json/wp/v2/posts | GET | อ่านรายการบทความ | สาธารณะ (ที่เผยแพร่แล้ว) |
| /wp-json/wp/v2/posts | POST | สร้างบทความใหม่ | Application Passwords |
| /wp-json/wc/v3/orders | GET | อ่านคำสั่งซื้อ WooCommerce | Consumer Key |
| /wp-json/wc/v3/orders | POST | สร้างคำสั่งซื้อใหม่ | Consumer Key |
| /wp-json/wp/v2/users | GET | อ่านรายการผู้ใช้ | รหัสผ่านผู้ดูแลระบบ |
| /wp-json/wp/v2/media | POST | อัปโหลดรูปภาพ | แก้ไขรหัสผ่านข้างต้น |
2. Webhook: การแจ้งเตือนเรียลไทม์ที่ขับเคลื่อนด้วยเหตุการณ์
Webhook กับ REST API ต่างกันตรงทิศทางครับ REST คือคุณเป็นฝ่ายไปดึงข้อมูลจากเซิร์ฟเวอร์ปลายทางเอง ส่วน Webhook คือเซิร์ฟเวอร์ปลายทางเป็นฝ่ายส่งข้อมูลมาหาคุณเมื่อมีเหตุการณ์เกิดขึ้น ตัวอย่างเช่น เมื่อ WooCommerce มีคำสั่งซื้อใหม่ มันจะส่ง POST request ไปยัง URL ที่คุณกรอกไว้ในหน้าตั้งค่า Webhook โดยใน body เป็น JSON รายละเอียดคำสั่งซื้อ คุณไม่ต้องคอย polling ว่ามีคำสั่งซื้อใหม่ไหมทุกนาที เพราะพอมีคำสั่งซื้อเข้ามามันจะ push มาหาเองอัตโนมัติ
WooCommerce รองรับ Webhook ในตัว เพิ่มได้ที่ WooCommerce → ตั้งค่า → ขั้นสูง → Webhooks คุณต้องกรอก: เหตุการณ์ที่ทริกเกอร์ (สร้างคำสั่งซื้อ, อัปเดตคำสั่งซื้อ, ยกเลิกคำสั่งซื้อ), URL ปลายทาง (endpoint บนเซิร์ฟเวอร์ของคุณเอง เช่น https://โดเมนของคุณ/wp-json/custom/v1/new-order), วิธีลงลายเซ็น (HMAC-SHA256 ใช้คีย์ลับยืนยันว่าคำขอมาจาก WooCommerce จริง ไม่ใช่คนอื่นปลอมมา)
ข้อสรุปที่ขัดกับสัญชาตญาณ:เมื่อ Webhook ส่งไม่สำเร็จ คุณมักไม่รู้ตัวเลย เมื่อ WooCommerce ส่ง Webhook ถ้าเซิร์ฟเวอร์ของคุณตอบกลับ 500 มันจะลองใหม่หลายครั้ง (ค่าเริ่มต้นสูงสุด 5 ครั้ง ระยะห่างเพิ่มขึ้นเรื่อยๆ) แต่ถ้าล้มเหลวครบ 5 ครั้ง มันจะเลิก ฝั่งคุณไม่ได้ข้อมูลและไม่มีการแจ้งเตือนใดๆ นี่คือเหตุผลว่าทำไมข้อมูลสำคัญจึงพึ่ง Webhook อย่างเดียวไม่ได้ — ต้องมีการดึงแบบตั้งเวลาเป็นตัวสำรอง วิธีเชื่อมต่อ CRM ดูที่การเชื่อมต่อ CRM สำหรับเว็บไซต์อิสระ。
| เหตุการณ์ | WooCommerce Hook | ส่งไปที่ไหน | ลำดับความสำคัญ |
|---|---|---|---|
| สร้างคำสั่งซื้อใหม่ | woocommerce_order_created | CRM + แจ้งเตือน Slack | สูงสุด |
| เปลี่ยนสถานะคำสั่งซื้อ | woocommerce_order_status_changed | อีเมลลูกค้า + อัปเดต CRM | สูง |
| ชำระเงินสำเร็จ | woocommerce_payment_complete | อัปเกรดระบบสมาชิก | สูง |
| เริ่มคืนเงิน | woocommerce_order_refunded | ติดแท็ก CRM + แจ้งฝ่ายการเงิน | ปานกลาง |
| สมัครสมาชิกใหม่ | user_register | รายชื่ออีเมลการตลาด | ปานกลาง |
| เปิด/ปิดการแสดงสินค้า | woocommerce_product_set_visibility | ซิงค์ระบบสต็อก | ต่ำ |
สาม การดึง REST แบบตั้งเวลา: กลไกกระทบยอดสำรอง
Webhook รับหน้าที่แจ้งเตือนเรียลไทม์ระดับวินาที แต่คุณต้องเพิ่มอีกชั้นคือการดึงแบบตั้งเวลาเพื่อกระทบยอด วิธีทำง่ายมาก เขียนสคริปต์ WP-Cron ให้รันทุกชั่วโมง เรียก WooCommerce REST API ดึงออเดอร์ที่สร้างหรืออัปเดตในชั่วโมงที่ผ่านมา มาเทียบกับออเดอร์ที่มีอยู่ในฐานข้อมูลของคุณ ถ้าเจอว่า Webhook ตกหล่นออเดอร์ใดไป (เช่น ตอนที่ Webhook ผลักมา เซิร์ฟเวอร์คุณตอบ 502 พอดี) การดึงแบบตั้งเวลาจะเติมออเดอร์นั้นกลับมาให้
พารามิเตอร์ query ของการดึงแบบตั้งเวลาต้องมี timestamp ด้วย เช่น GET /wp-json/wc/v3/orders?after=2026-09-21T10:00:00&per_page=100 จะคืนออเดอร์ทั้งหมดหลัง 10 โมง หน้าละ 100 รายการ ถ้าคืนมา 100 รายการ แปลว่าอาจมีมากกว่านั้น ให้เลื่อนหน้าดึงต่อ ดึงเสร็จแล้ว dedupe ตาม order ID รายการที่มีในฐานข้อมูลแล้วให้ข้าม รายการที่ไม่มีให้ insert นี่คือ logic การกระทบยอดที่ง่ายที่สุด
ตัวอย่างสถานการณ์: วันพุธบ่าย 3 โมง เซิร์ฟเวอร์มี SSL certificate หมดอายุ ตอบกลับ 525 นาน 40 นาที ช่วงนั้น Webhook ของออเดอร์ใหม่ 3 รายการล้มเหลวทั้งหมด ถ้ามีแค่ Webhook 3 ออเดอร์นี้ก็หายไปเลย แต่ถ้าตั้งการดึงแบบทุกชั่วโมงไว้ พอถึง 4 โมงก็จะเติม 3 ออเดอร์ที่ตกหล่นกลับมา ลูกค้าได้รับอีเมลยืนยัน วิธีตั้งค่าการมอนิเตอร์ ดูที่การมอนิเตอร์และแจ้งเตือนเว็บไซต์。
| วิธีซิงค์ | ความถี่ | ความหน่วง | การจัดการเมื่อล้มเหลว |
|---|---|---|---|
| Webhook push | ทริกเกอร์จากเหตุการณ์ | ระดับวินาที | อีกฝ่ายลองใหม่ 5 ครั้งแล้วเลิก |
| ดึงแบบตั้งเวลาทุกชั่วโมง | ทุกต้นชั่วโมง | ระดับนาที | ถ้าล้มเหลวครั้งหน้าลองใหม่ให้อัตโนมัติ |
| กระทบยอดเต็มรูปแบบรายวัน | ทุกวันตี 3 | ระดับวัน | สร้างรายงานส่วนต่างให้ตรวจด้วยคน |
| WebSocket แบบเรียลไทม์ | เรียลไทม์ | ระดับมิลลิวินาที | ถ้าการเชื่อมต่อขาดต้องเชื่อมใหม่ |
สี่、การยืนยันตัวตนและความปลอดภัย: เก็บ Key ไว้ฝั่งเซิร์ฟเวอร์ ตรวจลายเซ็นทุกคำขอ
ข้อผิดพลาดด้านความปลอดภัยที่พบบ่อยที่สุดในการเชื่อมต่อ API คือการเขียน API Key ไว้ใน JavaScript ฝั่งหน้าเว็บ ใครก็ตามที่เปิดเบราว์เซอร์กด F12 → แท็บ Network ก็จะเห็น Key ของคุณ แล้วเอาไปเรียก API ของคุณได้ตามใจ วิธีที่ถูกต้องคือ: ฝั่งหน้าเว็บเรียก API ของเซิร์ฟเวอร์ตัวเองเท่านั้น ให้เซิร์ฟเวอร์เติม API Key ฝั่งแบ็กเอนด์แล้วส่งต่อไปยังบุคคลที่สาม พร็อกซีฝั่งแบ็กเอนด์นี้จะเป็น REST endpoint แบบกำหนดเองของ WordPress ก็ได้ หรือจะเป็นบริการ Node.js/Python ง่ายๆ ก็ได้
ตอนรับ Webhook ต้องตรวจลายเซ็นเสมอ ตอน WooCommerce ส่ง Webhook จะเพิ่ม X-WC-Webhook-Signature ใน HTTP Header ซึ่งเป็นลายเซ็น HMAC-SHA256 ที่ทำจาก body ด้วย Webhook Secret ของคุณ คุณคำนวณลายเซ็นแบบเดียวกันใน endpoint ที่รับ แล้วเทียบกับใน Header ถ้าตรงกันจึงประมวลผล ถ้าไม่ตรงแสดงว่าเป็นคำขอปลอม ให้ตอบ 403 ไปเลย ผลของการไม่ตรวจลายเซ็นคือ: ใครก็ตามสามารถ POST ออเดอร์ปลอมเข้ามาที่ endpoint ของคุณได้ ใน CRM ของคุณก็จะมีลีดขยะโผล่ขึ้นมาเป็นกอง
ตัวอย่างสถานการณ์: คุณเชื่อม HubSpot Webhook มีคนรู้ URL ที่คุณใช้รับ เขาสร้างคำขอ POST “ลีดใหม่” ปลอมขึ้นมา ถ้าคุณไม่ตรวจลายเซ็น ลีดปลอมนี้ก็เข้าไปใน HubSpot ฝ่ายขายตามต่อตั้งนานกว่าจะรู้ว่าปลอม หลังเพิ่มการตรวจลายเซ็น HMAC คำขอจาก HubSpot มีลายเซ็นถูกต้อง ส่วนคำขอปลอมลายเซ็นไม่ถูกต้องก็ถูกบล็อกด้วย 403 ทันที รายละเอียดการเชื่อม CRM ดูได้ที่การเชื่อมต่อ CRM สำหรับเว็บไซต์อิสระ。
| รายการความปลอดภัย | วิธีที่ผิด | วิธีที่ถูกต้อง |
|---|---|---|
| ตำแหน่ง API Key | เขียนไว้ใน JS ฝั่งหน้าเว็บ | เก็บใน environment variable ของเซิร์ฟเวอร์ |
| พร็อกซีคำขอ | ฝั่งหน้าเว็บเรียก API บุคคลที่สามโดยตรง | ฝั่งหน้าเว็บเรียกเซิร์ฟเวอร์ตัวเอง แบ็กเอนด์ส่งต่อ |
| ตรวจลายเซ็น Webhook | ไม่ตรวจลายเซ็น รับแล้วประมวลผลเลย | เทียบ HMAC-SHA256 กับ Header |
| HTTPS | รับ Webhook ผ่าน HTTP | ต้องเป็น HTTPS, TLS 1.2 ขึ้นไป |
| IP whitelist | ไม่จำกัด IP ต้นทาง | whitelist ตามช่วง IP ทางการของบุคคลที่สาม |
| error log | ล้มเหลวแล้วไม่บันทึก | บันทึก log ทุกการตอบกลับที่ไม่ใช่ 2xx |
ห้า、รายการเชื่อมต่อบุคคลที่สามที่พบบ่อย
เว็บไซต์แบรนด์ของตัวเองมักมีการเชื่อมต่อกับระบบภายนอก 5 ประเภท ได้แก่ CRM (HubSpot, Salesforce, Zoho), อีเมลมาร์เก็ตติ้ง (Mailchimp, ConvertKit, Klaviyo), ระบบชำระเงิน (Stripe, PayPal), เครื่องมือวิเคราะห์ (Google Analytics 4, Hotjar) และระบบแชทลูกค้า (Intercom, Zendesk) วิธีเชื่อมต่อแต่ละประเภทไม่เหมือนกัน แต่ยึดหลักเดียวกันคือ ถ้าทำผ่าน Webhook ได้ก็ใช้ Webhook (เรียลไทม์) ส่วนข้อมูลสำคัญให้เพิ่มการดึงข้อมูลตามรอบเวลาด้วย (เป็นตัวสำรอง)
อย่าเพิ่งเริ่มเขียนโค้ดเชื่อมต่อเองตั้งแต่แรก ให้ดูก่อนว่าคลังปลั๊กอินของ WordPress มีปลั๊กอินสำเร็จรูปไหม HubSpot มีปลั๊กอินทางการ Mailchimp มีปลั๊กอินทางการ Stripe มีส่วนขยายทางการสำหรับ WooCommerce ปลั๊กอินสำเร็จรูปครอบคลุม 80% ของการใช้งาน ที่เหลืออีก 20% (เช่น การแมปฟิลด์แบบกำหนดเอง) ค่อยใช้ Webhook หรือเขียนโค้ดเองเสริม การเขียนโค้ดเชื่อมต่อสองระบบเองมักใช้เวลาแก้บั๊กเกิน 20 ชั่วโมง แต่ติดตั้งปลั๊กอินสำเร็จรูปใช้เวลาแค่ 1 ชั่วโมงก็เสร็จ วิธีเลือกปลั๊กอิน CRM ดูได้ที่ลีดจากเว็บไซต์ไปยัง CRM。
| ประเภทระบบ | 推荐方案 | วิธีเชื่อมต่อ | เวลาที่ใช้โดยประมาณ |
|---|---|---|---|
| CRM (HubSpot) | ปลั๊กอินทางการ + Webhook | ปลั๊กอินซิงค์อัตโนมัติ | 2 ถึง 4 ชั่วโมง |
| อีเมลมาร์เก็ตติ้ง (Mailchimp) | ปลั๊กอินทางการ | ผู้ใช้สมัครแล้วเพิ่มเข้ารายชื่ออัตโนมัติ | 1 ถึง 2 ชั่วโมง |
| ระบบชำระเงิน (Stripe) | ส่วนขยายทางการสำหรับ WooCommerce | Webhook ซิงค์สถานะคำสั่งซื้อ | 1 ถึง 2 ชั่วโมง |
| เครื่องมือวิเคราะห์ (GA4) | ปลั๊กอิน Site Kit by Google | ติดตั้งโค้ดติดตามอัตโนมัติที่ฝั่งหน้าเว็บ | 30 นาที |
| ระบบแชทลูกค้า (Intercom) | ปลั๊กอินแชททางการ | โค้ดฝังที่ฝั่งหน้าเว็บ | 30 นาที |
| ERP แบบกำหนดเอง | เขียน REST เชื่อมต่อเอง | ดึงข้อมูลตามรอบเวลา + Webhook | 20 ชั่วโมงขึ้นไป |
FAQ คำถามที่พบบ่อย
REST API กับ Webhook ต่างกันอย่างไร แบบไหนดีกว่า?
WordPress REST API ต้องติดตั้งปลั๊กอินไหม?
API Key ควรเก็บไว้ที่ไหน ใช้ที่ฝั่งหน้าเว็บได้ไหม?
ฝั่งที่รับ Webhook จะตรวจสอบได้ยังไงว่าคำขอเป็นของจริง?
ถ้า Webhook ส่งไม่สำเร็จจะทำยังไง?
การเชื่อมต่อกับระบบ third party ควรใช้ปลั๊กอินสำเร็จรูปหรือเขียนเอง?
ทิ้งท้าย
การเชื่อมต่อ API ไม่ใช่ยิ่งซับซ้อนยิ่งดี แต่ยิ่งเชื่อถือได้ยิ่งดี เป้าหมายมีอย่างเดียว: ข้อมูลไม่หาย, สถานะไม่ผิด, เกิดปัญหาแล้วตรวจสอบได้ Webhook เร็วแต่ไม่น่าเชื่อถือ REST ช้าแต่ควบคุมได้ เอาสองชั้นมาซ้อนกันจึงจะเป็นระดับ production ถ้าใช้อย่างใดอย่างหนึ่งเดี่ยว ๆ สักวันหนึ่งข้อมูลจะหายแน่นอน
ลงมือสามขั้น: การเชื่อมต่อที่สำคัญใช้ Webhook แจ้งแบบเรียลไทม์ และฝั่งที่รับเพิ่มการตรวจสอบ HMAC signature; เพิ่มการดึงข้อมูลผ่าน REST แบบตั้งเวลาทุกชั่วโมงเพื่อกระทบยอด ข้อมูลที่ Webhook ตกหล่นจะถูกดึงกลับมาอัตโนมัติ; เก็บ API Key ทั้งหมดไว้ใน environment variable ฝั่ง backend ให้ frontend เรียกผ่าน proxy ของเซิร์ฟเวอร์ตัวเองเท่านั้น
ประโยคเดียวที่จำง่าย: Webhook คือ “การแจ้งเตือนทันที” ส่วน REST คือ “การกระทบยอดเป็นรอบ” — ถ้าเชื่อแต่การแจ้งเตือนโดยไม่กระทบยอด ก็เหมือนฟังแค่เสียงกริ่งแต่ไม่ไปเช็คตู้พัสดุ