Thanawat Wongchai

Posted on Mar 26 • Originally published at apidog.com

วิธีส่ง SMS และ WhatsApp เร็วขึ้นด้วย Sent.dm API

สรุปสั้นๆ (TL;DR) / คำตอบด่วน

API ของ Sent.dm ให้จุดเชื่อมต่อเดียวสำหรับการส่งข้อความทางธุรกิจผ่าน SMS และ WhatsApp หากคุณจับคู่ Sent กับ Apidog คุณสามารถจัดเก็บข้อมูลรับรองของคุณในสภาพแวดล้อม ทดสอบคำขอโดยไม่ต้องเขียนสคริปต์แบบใช้แล้วทิ้ง ตรวจสอบเพย์โหลดของเว็บฮุค และจัดทำเอกสารขั้นตอนการทำงานของการส่งข้อความของคุณในที่เดียว

ทดลองใช้ Apidog วันนี้

บทนำ

โครงการส่งข้อความส่วนใหญ่ชะลอตัวลงในจุดเดียวกัน: ตัว API เองไม่ได้ยาก แต่รายละเอียดการปฏิบัติงานจะเพิ่มขึ้นอย่างรวดเร็ว คุณต้องมีคีย์ API, ตัวตนผู้ส่ง, รหัสเทมเพลต, ความปลอดภัยของเว็บฮุค, กฎช่องทาง และวิธีที่สะอาดในการทดสอบทั้งหมดโดยไม่ต้องส่งข้อความจริงแบบสุ่มสี่สุ่มห้า

นั่นคือเหตุผลที่ Sent.dm น่าสนใจ Sent วางตำแหน่งตัวเองเป็น API การส่งข้อความแบบรวมสำหรับ SMS และช่องทางที่อิงกับแอป เช่น WhatsApp พร้อมด้วยตรรกะการกำหนดเส้นทางและการส่งมอบที่จัดการอยู่เบื้องหลังอินเทอร์เฟซสำหรับนักพัฒนาเดียว จากเอกสารสาธารณะของ Sent ที่ตรวจสอบเมื่อวันที่ 26 มีนาคม 2026 แพลตฟอร์มประกอบด้วยการยืนยันบัญชี, การตั้งค่าช่องทาง, การส่งตามเทมเพลต, ผู้ติดต่อ, เหตุการณ์เว็บฮุค และสนามเด็กเล่นบนแดชบอร์ดสำหรับการทดสอบ

💡 หากคุณต้องการดำเนินการตั้งค่าดังกล่าวโดยมีข้อขัดแย้งน้อยลง Apidog เป็นเครื่องมือคู่หูที่แข็งแกร่ง คุณสามารถนำเข้าข้อมูลอ้างอิง API ของ Sent สร้างสภาพแวดล้อมที่นำกลับมาใช้ใหม่ได้สำหรับ x-api-key และ x-sender-id สร้างสถานการณ์การทดสอบเกี่ยวกับการสร้างข้อความและการจัดการเว็บฮุค และแบ่งปันคอลเล็กชันที่เสร็จสมบูรณ์กับทีมของคุณ ดาวน์โหลด Apidog ฟรี เพื่อทำตามบทช่วยสอนนี้

Sent.dm API แก้ปัญหาอะไร

Sent.dm สร้างขึ้นสำหรับทีมที่ต้องการเข้าถึงผู้ใช้ผ่านช่องทางการส่งข้อความมากกว่าหนึ่งช่องทางโดยไม่ต้องดูแลการรวมระบบแยกต่างหากสำหรับผู้ให้บริการแต่ละราย แทนที่จะเชื่อมต่อ API ของ SMS, การเริ่มต้นใช้งาน WhatsApp, รูปแบบเพย์โหลดเฉพาะช่องทาง และการตรวจสอบการส่งมอบด้วยตัวเอง Sent จะสรุปความซับซ้อนนั้นไว้ในแพลตฟอร์มเดียว

จากเอกสารทางการ เรื่องราวของผลิตภัณฑ์นั้นตรงไปตรงมา:

URL พื้นฐาน API เดียวสำหรับเวิร์กโฟลว์การส่งข้อความ
การตรวจสอบสิทธิ์แบบใช้ส่วนหัวด้วย x-api-key
โมเดลตัวตนผู้ส่งโดยใช้ x-sender-id
การส่งข้อความขาออกที่ขับเคลื่อนด้วยเทมเพลต
การจัดการผู้ติดต่อและกลุ่มเป้าหมาย
เว็บฮุคสำหรับเหตุการณ์การส่งมอบและเทมเพลต
แนวคิดการกำหนดเส้นทางอัจฉริยะและการเฟลโอเวอร์ในชั้นแพลตฟอร์ม

การรวมกันนี้มีความสำคัญเนื่องจากระบบการส่งข้อความไม่ค่อยมีเพียงแค่ "ส่งข้อความแล้วไปต่อ" คุณยังต้องการ:

โครงสร้างเพย์โหลดที่สอดคล้องกัน
วิธีที่ปลอดภัยในการใช้เทมเพลตซ้ำ
การติดตามเหตุการณ์สำหรับข้อความที่ส่งแล้ว, ล้มเหลว หรืออยู่ในคิว
ขั้นตอนการทำงานของการทดสอบที่เก็บความลับออกจากโค้ดส่วนหน้า
เอกสารที่นักพัฒนาและเพื่อนร่วมงาน QA ของคุณสามารถใช้ได้จริง

แอปพลิเคชัน → Message API → กฎช่องทาง → เหตุการณ์การส่งมอบ → การลองใหม่ / ตรรกะสถานะ

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

Sent.dm API ทำงานอย่างไร

เอกสารสาธารณะของ Sent อธิบายแพลตฟอร์มว่าเป็นชั้นกลางอัจฉริยะระหว่างแอปของคุณและช่องทางการส่งข้อความปลายทาง คำสัญญาที่เรียบง่าย: แอปของคุณส่งคำขอเดียว และ Sent จะเลือกเส้นทางการส่งมอบที่ดีที่สุดตามตรรกะการกำหนดเส้นทาง บริบทของผู้รับ และความพร้อมใช้งานของช่องทาง

1. การตั้งค่าบัญชีและการปฏิบัติตามข้อกำหนด

สร้างบัญชี, ยืนยัน KYC และตั้งค่าธุรกิจ การยืนยันบัญชีนี้ช่วยให้การส่งข้อความของคุณสอดคล้องกับกฎระเบียบและข้อจำกัดระดับภูมิภาค

2. การตั้งค่าช่องทาง

เลือกหมายเลขโทรศัพท์และเชื่อมต่อ WhatsApp Business แนะนำให้ใช้หมายเลขเดียวกันสำหรับ SMS และ WhatsApp เพื่อความสอดคล้องของแบรนด์

3. เทมเพลต

สร้างเทมเพลตข้อความก่อนที่จะส่งคำขอ API แรก เพื่อให้สามารถใช้ส่งข้อความตามเทมเพลตได้ทันที

4. ข้อมูลรับรอง API

Sent ใช้ข้อมูลรับรองสองชุด:

x-sender-id: YOUR_SENDER_ID
x-api-key: YOUR_API_KEY

ตรวจสอบข้อกำหนดส่วนหัวที่แน่นอนเทียบกับพื้นที่ทำงานและเอนด์พอยต์ที่คุณใช้

5. คำขอข้อความ

คำขอข้อความพื้นฐาน:

POST https://api.sent.dm/v2/messages/phone

เพย์โหลด:

{
  "phoneNumber": "RECIPIENT_PHONE_NUMBER",
  "templateId": "TEMPLATE_ID"
}

ตั้งค่าการส่งตามเทมเพลตก่อน แล้วค่อยขยายเวิร์กโฟลว์เมื่อเข้าใจการตอบสนองและพฤติกรรม API

ส่งคำขอ Sent.dm API ครั้งแรกของคุณ

ตัวอย่าง cURL

curl -X POST "https://api.sent.dm/v2/messages/phone" \
 -H "x-sender-id: YOUR_SENDER_ID" \
 -H "x-api-key: YOUR_API_KEY" \
 -H "Content-Type: application/json" \
 -d '{
   "phoneNumber": "RECIPIENT_PHONE_NUMBER",
   "templateId": "TEMPLATE_ID"
 }'

ตัวอย่าง JavaScript

const response = await fetch("https://api.sent.dm/v2/messages/phone", {
  method: "POST",
  headers: {
    "x-sender-id": process.env.SENT_SENDER_ID,
    "x-api-key": process.env.SENT_API_KEY,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    phoneNumber: process.env.TEST_PHONE_NUMBER,
    templateId: process.env.SENT_TEMPLATE_ID
  })
});

if (!response.ok) {
  throw new Error(`Sent request failed: ${response.status}`);
}

const data = await response.json();
console.log(data);

ตัวอย่าง Python

import os
import requests

response = requests.post(
    "https://api.sent.dm/v2/messages/phone",
    headers={
        "x-sender-id": os.environ["SENT_SENDER_ID"],
        "x-api-key": os.environ["SENT_API_KEY"],
        "Content-Type": "application/json",
    },
    json={
        "phoneNumber": os.environ["TEST_PHONE_NUMBER"],
        "templateId": os.environ["SENT_TEMPLATE_ID"],
    },
    timeout=30,
)

response.raise_for_status()
print(response.json())

API จะคืนค่า HTTP 200 และ messageId ตรวจสอบค่า messageId ใน Apidog tests, logs, หรือใน workflow ของคุณ

ทดสอบ Sent.dm API ใน Apidog

Apidog ช่วยให้การทดสอบและการทำงานร่วมกันสำหรับการพัฒนา API ง่ายขึ้น

ขั้นตอนที่ 1: สร้างสภาพแวดล้อม Sent

ใน Apidog สร้าง Environment ด้วยตัวแปร:

base_url = https://api.sent.dm
sender_id = YOUR_SENDER_ID
api_key = YOUR_API_KEY
template_id = YOUR_TEMPLATE_ID
test_phone = RECIPIENT_PHONE_NUMBER

ข้อดี:

ไม่ hardcode ความลับ
สลับระหว่าง sandbox/staging/production ง่าย
แชร์คอลเล็กชันกับทีมแต่ละคนใช้ค่าแยกกันได้

ขั้นตอนที่ 2: สร้างคำขอเพียงครั้งเดียว

สร้างคำขอใหม่ใน Apidog:

Method: POST
URL: {{base_url}}/v2/messages/phone
Headers:
- x-sender-id: {{sender_id}}
- x-api-key: {{api_key}}
- Content-Type: application/json
Body:

{
  "phoneNumber": "{{test_phone}}",
  "templateId": "{{template_id}}"
}

ขั้นตอนที่ 3: เพิ่มการยืนยัน

เพิ่ม Test Script เช่น

pm.test("Status is 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Response contains a messageId", function () {
  const json = pm.response.json();
  pm.expect(json.messageId).to.exist;
});

ขั้นตอนที่ 4: เปลี่ยนให้เป็นสถานการณ์

การใช้ Scenario ใน Apidog:

ส่งข้อความ
เก็บ messageId
Query สถานะปลายทาง (ถ้ามี)
เปรียบเทียบกับ webhook event

ขั้นตอนที่ 5: เพิ่มตัวอย่างเว็บฮุคลงในคอลเล็กชันเดียวกัน

บันทึกตัวอย่างเพย์โหลด webhook:

{
  "field": "message.status",
  "messageId": "msg_123",
  "status": "delivered",
  "channel": "whatsapp"
}

ขั้นตอนที่ 6: เผยแพร่เอกสารภายใน

รวบรวม header, ตัวอย่างเพย์โหลด, การตอบสนอง, เหตุการณ์ webhook, และหมายเหตุในเอกสารเดียวแชร์กับทีม

จัดการเทมเพลต ผู้ติดต่อ และเว็บฮุคอย่างถูกวิธี

เทมเพลต

เก็บ templateId ไว้ใน environment/config
ติดป้ายกำกับเทมเพลตตามสถานะ, วัตถุประสงค์
แยกเทมเพลตทดสอบกับ production
จัดทำเอกสาร mapping เทมเพลตกับ user journey

Apidog ช่วยให้คุณเก็บตัวอย่างคำขอแต่ละเทมเพลตไว้ในคอลเล็กชันเดียวกัน

ผู้ติดต่อ

ระบุ source of truth ของ contact
ทำให้หมายเลขโทรศัพท์เป็นมาตรฐาน
จัดเก็บสถานะ opt-in/consent
วางแผนสำหรับ contact switching channel

เว็บฮุค

Sent รองรับ HMAC-SHA256 webhook signatures:

x-webhook-signature
x-webhook-id
x-webhook-timestamp

ตัวอย่าง Express:

import crypto from "crypto";
import express from "express";

const app = express();

app.post("/webhooks/sent", express.raw({ type: "*/*" }), (req, res) => {
  const signature = req.header("x-webhook-signature");
  const webhookId = req.header("x-webhook-id");
  const timestamp = req.header("x-webhook-timestamp");
  const secret = process.env.SENT_WEBHOOK_SECRET;
  const rawBody = req.body.toString("utf8");

  const signedContent = `${webhookId}.${timestamp}.${rawBody}`;
  const expected = crypto
    .createHmac("sha256", Buffer.from(secret.replace(/^whsec_/, ""), "base64"))
    .update(signedContent)
    .digest("base64");

  if (signature !== `v1,${expected}`) {
    return res.status(401).send("Unauthorized");
  }

  const event = JSON.parse(rawBody);
  console.log("Received webhook event:", event.field);

  return res.sendStatus(200);
});

ใช้ Apidog เก็บตัวอย่าง webhook payload เพื่อให้ทีม dev/frontend/QA เข้าใจตรงกัน

เหตุผลที่ Apidog เหมาะกับเวิร์กโฟลว์นี้

Sent.dm ให้เลเยอร์การส่งข้อความ Apidog ให้เลเยอร์เวิร์กโฟลว์รอบ API เหล่านั้น

งาน	Sent.dm	Apidog
ส่งข้อความ SMS และ WhatsApp	ใช่	ไม่ (แต่ทดสอบ API)
จัดการเทมเพลต/ผู้ส่ง	ใช่	ตรวจสอบคำขอ, เอกสาร
ทดสอบคำขอที่ตรวจสอบสิทธิ์	พื้นฐาน	สร้างคำขอ + ยืนยัน + สถานการณ์
แชร์เอกสาร API กับทีม	เอกสารแพลตฟอร์ม	คอลเล็กชันและเอกสารที่แชร์ได้
ดีบักโฟลว์คำขอ/ตอบกลับ	บางส่วน	ดีกว่าสำหรับรีวิว/ทำงานร่วมกัน
สร้าง End-to-End test	เน้นการส่งข้อความ	ดีกว่าสำหรับ workflow หลายขั้นตอน

สำหรับทีมที่ต้องการแชร์คอลเล็กชัน, ให้ QA ทดสอบ API, หรือทดสอบเวอร์ชัน/เทมเพลตใหม่ในสภาพแวดล้อมเดียว ดาวน์โหลด Apidog ฟรี เพื่อสร้างเวิร์กโฟลว์ที่นำกลับมาใช้ใหม่ได้

เคล็ดลับขั้นสูงและข้อผิดพลาดทั่วไป

แนวทางปฏิบัติที่ดีที่สุด

เก็บข้อมูลรับรองไว้ฝั่ง server-side เท่านั้น
ติดตาม messageId ใน log และ support tools
แยก staging/production template
ตรวจสอบ webhook ทุกครั้ง
ใช้ Apidog environments แยก prod/test credentials

ข้อผิดพลาดที่ควรหลีกเลี่ยง

เข้าใจผิดว่า HTTP 200 คือความสำเร็จสุดท้าย
hardcode templateId ในหลาย service
ละเลย sender identity ตั้งแต่ต้น
ไม่ normalize หมายเลขโทรศัพท์
ทดสอบด้วย real credentials ใน adhoc script

จุดแก้ไขปัญหา

x-api-key ถูกต้องหรือไม่
เอนด์พอยต์กับ workspace/เวอร์ชันตรงกันหรือไม่
จำเป็นต้องใช้ x-sender-id หรือไม่
เทมเพลตได้รับอนุมัติหรือยัง
หมายเลขโทรศัพท์อยู่ในรูปแบบที่ถูกต้องหรือไม่

เปรียบเทียบคำขอที่ล้มเหลวกับตัวอย่างใน Apidog ได้รวดเร็ว

ทางเลือกและการเปรียบเทียบ Sent.dm

ตัวเลือก	จุดแข็ง	ข้อเสีย
ผู้ให้บริการ SMS + WhatsApp โดยตรง	ควบคุมละเอียด	รวม/ดูแลระบบมาก
Twilio stack	ระบบนิเวศกว้าง	การประสานงานหลายช่องทางซับซ้อน
Sent.dm	เวิร์กโฟลว์รวม	ขึ้นกับโครงสร้าง Sent
Sent.dm + Postman	โฟลว์ test คุ้นเคย	เอกสาร/ออกแบบ/ทำงานร่วมกันยังแยก
Sent.dm + Apidog	รวม API + ทดสอบ/เอกสาร/แชร์เวิร์กโฟลว์	ใช้ 2 เครื่องมือ

ทีมที่เน้นความเร็ว dev ให้จับคู่ platform ส่งข้อความกับเครื่องมือ API ที่ทำงานร่วมกันได้ เช่น Apidog ไม่ใช่แค่ส่งคำขอ แต่รวม environment/เอกสาร/validate/test scenario ใน workspace เดียว

บทสรุป

Sent.dm คือ API สำหรับส่งข้อความ SMS/WhatsApp แบบรวมที่เน้นการตั้งค่าและการส่งข้อความตามเทมเพลต ข้อดีคือสามารถทดสอบ, ตรวจสอบ, และจัดการรอบ template, sender, contact, และ webhook ได้อย่างมีโครงสร้าง

เริ่มต้นด้วยการสร้างคำขอแรกใน Apidog เพิ่ม test สำหรับ messageId และจัดทำเอกสาร webhook contract ใน workspace เดียว ช่วยให้โฟลว์ clean กว่าการใช้ script กระจัดกระจาย

คำถามที่พบบ่อย

Sent.dm API ใช้สำหรับอะไร?

ส่งข้อความทางธุรกิจผ่าน SMS และ WhatsApp โดยมีระบบเทมเพลต, ผู้ส่ง, ผู้ติดต่อ, และ webhook

Sent.dm รองรับ WhatsApp และ SMS ใน API เดียวกันหรือไม่?

ใช่ เป็น API รวมที่ซ่อนความซับซ้อนของแต่ละช่องทางไว้หลัง API เดียว

ฉันต้องการส่วนหัวใดบ้างสำหรับคำขอ Sent.dm API?

x-api-key เป็นหลัก และส่วนใหญ่ใช้ x-sender-id ด้วย ตรวจสอบเอนด์พอยต์ใน workspace ของคุณ

ฉันต้องมีเทมเพลตก่อนที่จะส่งข้อความด้วย Sent.dm หรือไม่?

ต้องมี เทมเพลตต้องถูกสร้างและอนุมัติก่อนใช้งาน

ฉันจะทดสอบ Sent.dm API โดยไม่ต้องเขียนสคริปต์ที่กำหนดเองได้อย่างไร?

ใช้ Apidog จัดเก็บ environment, บันทึกคำขอ, เพิ่ม test, สร้าง scenario, จัดเอกสาร webhook และเผยแพร่กับทีม

ฉันควรจะรักษาความปลอดภัยเว็บฮุคของ Sent.dm อย่างไร?

ตรวจสอบ HMAC signature, timestamp, และทำ event แบบ idempotent ตามเอกสาร (ใช้ header: x-webhook-signature, x-webhook-id, x-webhook-timestamp)

Sent.dm เพียงพอด้วยตัวมันเองสำหรับเวิร์กโฟลว์ API ของทีมหรือไม่?

สำหรับ layer ส่งข้อความเพียงพอ แต่การทดสอบ, เอกสาร, ทำงานร่วมกันในทีมควรใช้เครื่องมือ API เพิ่มเติม เช่น Apidog