SNS Webhook Bypass(การส่งต่อ Webhook ของ SNS ภายนอกอย่าง LINE)

Webhook SNS LINE Bypass การส่งต่อ การเชื่อมต่ออีเวนต์
บทความนี้เหมาะสำหรับใคร
สำหรับนักพัฒนาที่ต้องการรับ Webhook ของ SNS ภายนอกอย่าง LINE(การรับข้อความ, ฟอลโลว์, โพสต์แบ็ก ฯลฯ)มาที่แอปของตัวเองผ่าน ReceiptRoller บทความนี้อธิบายกลไกและวิธีตั้งค่าของฟีเจอร์ "SNS Webhook Bypass"

ReceiptRoller รับ Webhook ที่ส่งมาจาก SNS ภายนอก(LINE Official Account, Meta, X ฯลฯ)ที่ร้านค้าเชื่อมต่อไว้ แล้วนำไปใช้กับการตอบกลับอัตโนมัติและการประมวลผลแคมเปญ อีเวนต์ดิบเหล่านี้ หากได้รับความยินยอมอย่างชัดแจ้งจากฝั่งร้านค้า นักพัฒนาก็สามารถให้ส่งต่อไปยังเอนด์พอยต์ที่ลงทะเบียนไว้แบบตรงๆ ได้ นี่คือ "SNS Webhook Bypass"

ใช้ในกรณีเช่นนี้

  • ต้องการนำข้อความจาก LINE Official Account เข้า CRM ของบริษัทเอง
  • ต้องการเริ่มการประมวลผลออนบอร์ดดิงของตัวเองจากฟอลโลว์อีเวนต์
  • ต้องการสร้างการเชื่อมต่อริชเมนูของตัวเองโดยใช้โพสต์แบ็ก
  • ต้องการแจ้งเมนชัน・รีพลายของ SNS ไปยังเครื่องมือภายในบริษัท

เป็นทางเลือกสำหรับกรณีที่ต้องการลอจิกทางธุรกิจของตัวเองที่เกินขอบเขตที่ฟีเจอร์ตอบกลับอัตโนมัติของฝั่ง ReceiptRoller ทำได้

กลไก

[LINE / Meta / X ฯลฯ]
        │ Webhook(มีลายเซ็นของแพลตฟอร์ม)
        ▼
[เอนด์พอยต์รับของ ReceiptRoller]
        │ ① ตรวจสอบลายเซ็นของแพลตฟอร์ม
        │ ② ประมวลผลทางธุรกิจของตัวเอง(ตอบกลับอัตโนมัติ・รวมยอด ฯลฯ)
        │ ③ หากตั้งค่า bypass เป็น ON จะส่งต่อไปยังเอนด์พอยต์ของนักพัฒนา
        ▼
[แอปของนักพัฒนา]
        ・รู้ว่า SNS ต้นทางคืออะไรจาก X-RR-Source-Platform
        ・ยืนยันลายเซ็นต้นฉบับได้จาก X-RR-Original-Signature
        ・ReceiptRoller ยังแนบลายเซ็นของตัวเองมาด้วยผ่าน X-RR-Signature

ReceiptRoller เพียง "รีเลย์เท่านั้น" เนื้อในของเพย์โหลดที่ส่งต่อยังเป็นรูปแบบดิบจากฝั่ง SNS ตามเดิม หากเป็น Webhook ของ LINE ก็จะเป็น JSON ของ LINE, ของ Meta ก็จะเป็น JSON ของ Meta ที่มาถึงตามเดิม ด้วยเหตุนี้ นักพัฒนาจึงสามารถนำ SDK หรือเอกสารทางการของแต่ละ SNS มาใช้ต่อได้ตามเดิม

วิธีตั้งค่า(ผู้จัดการร้านค้าเป็นผู้ดำเนินการ)

Bypass ต้องเปิดใช้งานอย่างชัดแจ้งจากฝั่งร้านค้า นักพัฒนาโปรดแนะนำขั้นตอนของหน้านี้แก่ผู้จัดการร้านค้า

  1. ล็อกอินหน้าจอจัดการของ ReceiptRoller
  2. เมนูด้านซ้าย "บัญชีธุรกิจ" → "บัญชี SNS"
  3. เปิด "แก้ไข" ของบัญชี SNS ที่เกี่ยวข้อง(เช่น LINE Official Account)
  4. เปิดเซกชัน "Webhook Bypass"
  5. สลับ "เปิดใช้งาน Bypass" เป็น ON
  6. เลือกแอปของนักพัฒนาที่จะเป็นปลายทางส่งต่อ(ต้องลงทะเบียนแอปไว้ล่วงหน้า)
  7. เลือกชนิดอีเวนต์ที่จะส่งต่อ(เช่น message, follow, postback
  8. คลิก "บันทึก"
สำคัญ:Bypass เป็นฟีเจอร์ที่ส่งอีเวนต์ดิบที่มีข้อมูลส่วนบุคคลออกไปภายนอก โปรดเปิดใช้งานภายใต้ความรับผิดชอบของฝั่งร้านค้า หลังจากได้จัดเตรียมวัตถุประสงค์การใช้งาน・สัญญา・นโยบายความเป็นส่วนตัวที่เหมาะสมแล้ว

เฮดเดอร์ตอนส่งต่อ

ชื่อเฮดเดอร์ เนื้อหา
X-RR-Source-Platform แพลตฟอร์มต้นทาง(line / meta / x / tiktok ฯลฯ)
X-RR-Source-Account-Id SNS account ID ภายในของ ReceiptRoller
X-RR-Original-Signature ลายเซ็นต้นฉบับของฝั่ง SNS(เช่น หาก LINE คือค่าของ x-line-signature
X-RR-Signature ลายเซ็น HMAC-SHA256 ที่ ReceiptRoller แนบให้
X-RR-Timestamp เวลาที่ส่งต่อ(Unix วินาที)
X-RR-Event-Id อีเวนต์ ID ที่ไม่ซ้ำซึ่ง ReceiptRoller แนบให้(คีย์สำหรับ idempotency)
บอดี เพย์โหลดดิบจากฝั่ง SNS(ไม่ผ่านการแปลง)

การตรวจสอบลายเซ็น

ฝั่งรับสามารถตรวจสอบลายเซ็นได้ 2 แบบตามการใช้งาน

วิธี A:ตรวจสอบลายเซ็นของ ReceiptRoller(แนะนำ)

ตรวจสอบ X-RR-Signature ด้วยวิธีเดียวกับ Webhook ปกติของ ReceiptRoller เนื่องจากสามารถรวมลอจิกการตรวจสอบให้เหลือแบบเดียวได้ การดำเนินงานจึงง่ายขึ้น รายละเอียดโปรดดูการตรวจสอบลายเซ็นและความปลอดภัย

วิธี B:ตรวจสอบลายเซ็น SNS ต้นฉบับ

เนื่องจากบอดีเป็นรูปแบบดิบจากฝั่ง SNS ตามเดิม จึงสามารถใช้ SDK ของแต่ละ SNS ตรวจสอบลายเซ็นต้นฉบับ(X-RR-Original-Signature)ได้ด้วย สะดวกในกรณีที่ต้องการนำโค้ดตัวอย่างของ LINE Official SDK มาใช้ต่อตามเดิม เป็นต้น แต่ในกรณีนี้ นักพัฒนาจำเป็นต้องถือแชนเนลซีเคร็ตของฝั่ง SNS ไว้เอง

ตัวอย่างการรับ(LINE)

POST /your/endpoint HTTP/1.1
Content-Type: application/json
X-RR-Source-Platform: line
X-RR-Source-Account-Id: sns_a1b2c3
X-RR-Original-Signature: aXyZ...(ลายเซ็นที่ LINE ออก)
X-RR-Signature: 9f8e7d...(HMAC ที่ RR ออก)
X-RR-Timestamp: 1745740000
X-RR-Event-Id: evt_01HV6N...

{
  "destination": "U1234567890...",
  "events": [
    {
      "type": "message",
      "message": { "type": "text", "id": "...", "text": "สวัสดี" },
      "timestamp": 1745739999000,
      "source": { "type": "user", "userId": "U..." },
      "replyToken": "..."
    }
  ]
}

ส่วนบอดีเป็นสิ่งที่รับมาจาก LINE ตามเดิม จึงสามารถส่งเข้า WebhookParser ของ LINE Messaging API SDK ได้ตรงๆ

ข้อควรระวังเกี่ยวกับการตอบกลับ

ใน bypass เอนด์พอยต์ของนักพัฒนาเพียงคืน 2xx เท่านั้นก็พอ ส่วนข้อความรีพลายและอื่นๆ ให้เรียก SNS API โดยตรงจากฝั่งนักพัฒนาเพื่อส่ง ReceiptRoller ไม่รีเลย์การตอบกลับให้

  • หากใช้ replyToken ของ LINE นักพัฒนาต้อง POST ตรงไปยัง LINE Messaging API
  • เพื่อการนั้น จำเป็นต้องจัดการ LINE channel access token ของร้านค้าแยกต่างหาก
  • วิธีการขอปรับตามแต่ละร้านค้า(authorization flow ของแพลตฟอร์ม หรือแชร์ด้วยมือจากร้านค้า)

การส่งซ้ำ・idempotency

อีเวนต์ที่ส่งต่อก็เหมือน Webhook ปกติ คือหากไม่ใช่ 2xx จะถูกส่งซ้ำสูงสุด 7 ครั้ง โปรดอิมพลิเมนต์การตรวจสอบ idempotency ด้วย event_id เสมอ รายละเอียดดูการออกแบบการส่งซ้ำ・ลำดับ・idempotency

ข้อควรระวังคือ แม้ Webhook ต้นฉบับของฝั่ง SNS จะถูกประมวลผลไปแล้วในแชนเนลอื่น(เช่น การประมวลผลตอบกลับอัตโนมัติ)ก่อนหน้า bypass ก็จะส่งต่ออย่างเป็นอิสระ โปรดออกแบบทั้งสองอย่างแยกกัน

ข้อจำกัด

  • แพลตฟอร์มที่รองรับ:LINE, Meta(Facebook/Instagram), X, TikTok, YouTube, Pinterest, LinkedIn, GBP(กำลังทยอยขยาย)
  • ต่อ 1 บัญชี SNS ส่งต่อได้ไปยังแอปได้ 1 แอปเท่านั้น
  • ชนิดอีเวนต์ที่ส่งต่อได้เฉพาะที่เกิดขึ้นจากฝั่ง SNS เท่านั้น ไม่รวมอีเวนต์เฉพาะของ ReceiptRoller
  • Bypass ใช้งานได้ตั้งแต่แพลน Starter ขึ้นไป
  • เกณฑ์ความหน่วงของการส่งต่อโดยปกติภายใน 1 วินาที(หลังรับจากแพลตฟอร์ม)

ข้อควรระวังด้านความปลอดภัยและความเป็นส่วนตัว

  • บอดีที่ส่งต่ออาจมีข้อมูลส่วนบุคคล เช่น LINE user ID หรือเนื้อหาข้อความ
  • นโยบายความเป็นส่วนตัวของฝั่งร้านค้าต้องระบุการส่งต่อไปยังนักพัฒนาภายนอกด้วย
  • ฝั่งนักพัฒนาเองก็ต้องทำให้ชัดเจนถึงขอบเขตการจัดเก็บ・การใช้งานข้อมูลที่รับมา ผ่านสัญญากับร้านค้า
  • ตอนทดสอบ แนะนำให้ใช้บัญชี SNS สำหรับทดสอบโดยเฉพาะ เพื่อหลีกเลี่ยงการจัดการข้อมูลลูกค้าจริง

คู่มือที่เกี่ยวข้อง

วันที่เผยแพร่: 2569-04-27 วันที่อัปเดต: 2569-07-05
แท็ก
API (22) OAuth (15) Android (10) iOS (9) Webhook (8) api (7) oauth (5) getting-started (4) การลงทะเบียนแอป (4) การแก้ปัญหา (4)
บทความที่เกี่ยวข้อง