ภาพรวม Webhook

วิธีที่ ThunderPhone ส่งเหตุการณ์แบบเรียลไทม์ วิธีตรวจสอบลายเซ็น และการเปรียบเทียบโมเดลการส่งแบบเดิมกับแบบอิงปลายทาง

ThunderPhone ส่งคำขอ HTTP POST ไปยังเซิร์ฟเวอร์ของคุณเมื่อมีเหตุการณ์ ระหว่างการโทร เช่น สายเรียกเข้าเริ่มต้น สายสิ้นสุด การประเมินเสร็จสมบูรณ์ การแจ้งเตือนทำงาน เป็นต้น โดยมี รูปแบบการนำส่งสองแบบ:

เหตุการณ์ทั้งสิบประเภทในแค็ตตาล็อกเหตุการณ์ จะถูกนำส่งผ่าน webhook endpoint เหตุการณ์ตลอดวงจรการโทรทั้งหกรายการ (telephony.incoming, telephony.complete, telephony.tool, web.incoming, web.complete, web.tool) จะถูกส่งไปยัง webhook แบบเดิมสำหรับ URL เดียว ด้วย — หากคุณมีทั้ง URL แบบเดิมและ endpoint ที่ตรงกัน คุณจะได้รับเหตุการณ์ผ่านเส้นทาง ทั้งสอง เส้นทาง พฤติกรรมแบบบล็อก (การแลกเปลี่ยนการกำหนดค่า telephony.incoming / web.incoming และการส่งต่อเครื่องมือในโหมด webhook) มีอยู่เฉพาะบนเส้นทางแบบเดิมเท่านั้น การนำส่งไปยัง endpoint ทุกครั้งเป็นการแจ้งเตือน แบบส่งแล้วไม่รอผลลัพธ์

รูปแบบเพย์โหลด#

การนำส่งไปยัง endpoint เป็นออบเจ็กต์ JSON ที่มี data, event_id และ type:

{
  "data": {
    "call_id": 987654321,
    "from_number": "+14155550199",
    "to_number": "+15551234567"
  },
  "event_id": "3f6b2ad0-1c9e-4a57-9f2b-8f6f0f9d2f11",
  "type": "telephony.incoming"
}

event_id ไม่ซ้ำกันสำหรับแต่ละเหตุการณ์ที่ส่งออก โดยมีค่าเหมือนกันในการลองส่งซ้ำ และ ในทุก endpoint ที่ได้รับเหตุการณ์ — ใช้ค่านี้กำจัดรายการซ้ำ

Webhook แบบเดิมสำหรับ URL เดียวจะส่ง type และ data เดียวกัน แต่ ไม่มี event_id:

{
  "type": "telephony.incoming",
  "data": { "call_id": 987654321, "from_number": "+14155550199", "to_number": "+15551234567" }
}

ในการส่งผ่านเครือข่าย เนื้อหาทุกรายการจะถูกซีเรียลไลซ์แบบมาตรฐาน — คีย์เรียงตาม ตัวอักษร ไม่มีช่องว่าง และใช้ UTF-8 ตัวอย่างที่จัดรูปแบบให้อ่านง่ายในเอกสารนี้ มีไว้เพื่อให้อ่านง่ายเท่านั้น

ดูแค็ตตาล็อกเหตุการณ์สำหรับรายการประเภทเหตุการณ์และฟิลด์ เพย์โหลดทั้งหมด

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

ทุกคำขอมีลายเซ็น HMAC-SHA256 ของ เนื้อหาคำขอแบบดิบ ทั้งหมด อยู่ในเฮดเดอร์ X-ThunderPhone-Signature คีย์สำหรับลงลายเซ็นคือ secret ของเอนด์พอยต์ (หรือ secret ของ webhook ระดับองค์กรสำหรับ การส่งแบบเดิม)

ขั้นตอน#

1. อ่านเนื้อหาคำขอแบบดิบ ก่อน ทำการแยกวิเคราะห์ใดๆ
2. คำนวณ hmac_sha256(secret, body).hexdigest()
3. เปรียบเทียบกับเฮดเดอร์ X-ThunderPhone-Signature ด้วยเวลาคงที่

เราลงลายเซ็นไบต์ที่เราส่งอย่างตรงตัว และไบต์เหล่านั้นคือ การจัดรูปแบบ JSON มาตรฐาน (เรียงลำดับคีย์ ตัวคั่นแบบกระชับ) ดังนั้น การตรวจสอบกับเนื้อหาแบบดิบจึงใช้ได้เสมอ และหากเฟรมเวิร์กของคุณ ส่งให้เฉพาะ JSON ที่แยกวิเคราะห์แล้ว การจัดรูปแบบใหม่โดยเรียงลำดับคีย์และ ใช้ตัวคั่นแบบกระชับจะสร้างไบต์ที่เหมือนกัน ทั้งสองวิธีมีอธิบายไว้ใน คู่มือการตรวจสอบ

import hmac
import hashlib
 
def verify_signature(body: bytes, signature: str, secret: str) -> bool:
    expected = hmac.new(
        secret.encode("utf-8"),
        body,
        hashlib.sha256,
    ).hexdigest()
    return hmac.compare_digest(expected, signature or "")
 
# Example Flask handler
from flask import Flask, request, abort
app = Flask(__name__)
 
@app.post("/thunderphone-webhook")
def handle():
    body = request.get_data()
    sig = request.headers.get("X-ThunderPhone-Signature", "")
    if not verify_signature(body, sig, WEBHOOK_SECRET):
        abort(401)
    event = request.get_json()
    # dispatch on event["type"] …
    return "", 204

import crypto from "node:crypto";
import express from "express";
 
function verifySignature(body, signature, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(body)
    .digest("hex");
  if (!signature || expected.length !== signature.length) return false;
  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(signature),
  );
}
 
const app = express();
app.post(
  "/thunderphone-webhook",
  express.raw({ type: "application/json" }),
  (req, res) => {
    const sig = req.header("X-ThunderPhone-Signature") || "";
    if (!verifySignature(req.body, sig, process.env.WEBHOOK_SECRET)) {
      return res.sendStatus(401);
    }
    const event = JSON.parse(req.body.toString("utf8"));
    // dispatch on event.type …
    res.sendStatus(204);
  },
);

ความหมายของการส่ง#

ความหมายเหล่านี้ใช้กับการส่งไปยัง ปลายทาง Webhook แบบ URL เดี่ยวรุ่นเก่าเป็นการพยายามแบบซิงโครนัสเพียงครั้งเดียวโดยไม่มีการลองใหม่

การเลือกระหว่าง Webhook รุ่นเก่าและ Webhook แบบปลายทาง#

การผสานรวมใหม่ควรรับเหตุการณ์ผ่าน Webhook แบบปลายทาง เก็บ URL รุ่นเก่าไว้ (หรือเพิ่ม URL รุ่นเก่า) เฉพาะเมื่อคุณกำหนดค่าสายแบบไดนามิกขณะรับสาย หรือใช้การเรียกใช้เครื่องมือโหมด Webhook — การแลกเปลี่ยนคำขอ/การตอบกลับเหล่านั้นทำงานได้เฉพาะบนเส้นทางรุ่นเก่า

ที่เกี่ยวข้อง#