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

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

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

บทนำ

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

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

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 และการตั้งค่าธุรกิจ นี่ไม่ใช่การดูแลบ้านที่ไม่จำเป็น ผลิตภัณฑ์การส่งข้อความเกี่ยวข้องกับกฎการปฏิบัติตามข้อกำหนด ชื่อเสียงของผู้ส่ง และข้อจำกัดระดับภูมิภาค ดังนั้น Sent จึงทำให้การยืนยันบัญชีเป็นส่วนหนึ่งของเส้นทางการเริ่มต้นใช้งาน

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

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

3. เทมเพลต

เทมเพลตเป็นส่วนสำคัญของขั้นตอนการทำงาน ในคู่มือเริ่มต้นใช้งาน Sent ให้คุณสร้างเทมเพลตก่อนที่จะส่งคำขอ API ครั้งแรก นั่นเป็นสัญญาณที่ดีว่าการส่งข้อความตามเทมเพลตไม่ใช่กรณีพิเศษที่นี่ แต่เป็นส่วนหนึ่งของเส้นทางเริ่มต้น

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

เอกสารแสดงข้อมูลรับรองสองชุด:

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

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

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

คู่มือเริ่มต้นใช้งานแสดงคำขอไปยัง:

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

ด้วยเพย์โหลด JSON ที่มีรูปร่างดังนี้:

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

นั่นบอกคุณถึงสิ่งสำคัญเกี่ยวกับเป้าหมายการนำไปใช้ครั้งแรก: เส้นทางที่เร็วที่สุดไม่ใช่การสร้างบริการประสานงาน Omni-channel ขนาดใหญ่ แต่เป็นการตั้งค่าการส่งตามเทมเพลตอย่างถูกต้อง จากนั้นขยายขั้นตอนการทำงานเมื่อคุณสามารถสังเกตพฤติกรรมการขอและการส่งมอบได้อย่างน่าเชื่อถือ

ส่งคำขอ 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())

ตามเอกสารเริ่มต้นใช้งาน การตอบกลับที่สำเร็จจะส่งคืน HTTP 200 และ messageId ซึ่ง messageId นี้คือค่าที่คุณต้องการจับใน Apidog tests, application logs, support workflows และ webhook reconciliation

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

นี่คือจุดที่ Apidog กลายเป็นมากกว่าแค่ตัวเรียกคำขอ API การส่งข้อความทำงานได้ง่ายขึ้นเมื่อคำขอ, ตัวแปร, การยืนยันการทดสอบ, เอกสาร และการส่งมอบงานในทีมอยู่ร่วมกันทั้งหมด

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

ใน Apidog ให้สร้างสภาพแวดล้อมด้วยตัวแปรเช่น:

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

การใช้ตัวแปรสภาพแวดล้อมให้ประโยชน์สามประการทันที:

1. คุณหลีกเลี่ยงการ hardcode ความลับในการผลิตในตัวอย่าง
2. คุณสามารถสลับระหว่างบัญชี sandbox, staging และ live ได้เร็วขึ้น
3. เพื่อนร่วมงานสามารถนำคอลเล็กชันเดียวกันไปใช้ซ้ำกับค่าที่ปลอดภัยของตนเองได้

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

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

- x-sender-id: {{sender_id}} - x-api-key: {{api_key}} - Content-Type: application/json

• เมธอด: POST
• URL: {{base_url}}/v2/messages/phone
• ส่วนหัว:
• เนื้อหา:

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

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

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

ใน Apidog ให้เพิ่มการทดสอบที่ตรวจสอบเส้นทางที่สำเร็จ

ตัวอย่างการตรวจสอบ:

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;
});

การตรวจสอบเหล่านี้ช่วยให้คุณตรวจพบข้อผิดพลาดเล็กน้อยได้อย่างรวดเร็ว หากคำขอหยุดส่งคืน message ID หลังจากมีการเปลี่ยนแปลง API, การหมุนเวียนข้อมูลรับรอง หรือปัญหาเทมเพลต คุณจะเห็นมันทันที

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

Apidog มีประโยชน์มากยิ่งขึ้นเมื่อคุณเปลี่ยนจากการร้องขอเดียวไปสู่เวิร์กโฟลว์:

1. ส่งข้อความ
2. จัดเก็บ messageId ที่ส่งคืน
3. สอบถามสถานะปลายทางหากการตั้งค่าของคุณเปิดเผยโฟลว์นั้น
4. เปรียบเทียบเหตุการณ์ข้อความที่ได้รับผ่านเว็บฮุค

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

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

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

ตัวอย่างเช่น คุณสามารถบันทึกตัวอย่างเพย์โหลดเว็บฮุคและจัดทำเอกสารฟิลด์ต่างๆ เช่น:

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

สิ่งนี้จะให้ผลตอบแทนอย่างรวดเร็ว วิศวกรแบ็คเอนด์สามารถเปรียบเทียบเพย์โหลดจริงกับตัวอย่างที่บันทึกไว้ QA สามารถตรวจสอบตรรกะการจัดการเหตุการณ์ และทีมสนับสนุนสามารถเข้าใจว่าสถานะข้อความหมายถึงอะไรโดยไม่ต้องขุดคุ้ยบันทึก

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

หากทีมของคุณมีวิศวกรแบ็คเอนด์, QA, ทีมสนับสนุน และผู้มีส่วนได้ส่วนเสียในผลิตภัณฑ์ที่เกี่ยวข้องกับขั้นตอนการส่งข้อความเดียวกัน, เลเยอร์เอกสารของ Apidog จะช่วยประหยัดเวลา แทนที่จะแบ่งปันสคริปต์ cURL แบบหลวมๆ ในแชท คุณสามารถเผยแพร่เอกสารอ้างอิงภายในที่ชัดเจนซึ่งรวมถึง:

• ส่วนหัวที่จำเป็น
• ตัวอย่างเพย์โหลด
• การตอบสนองข้อผิดพลาด
• ตัวอย่างเหตุการณ์เว็บฮุค
• หมายเหตุเกี่ยวกับสภาพแวดล้อม

นั่นเป็นการส่งมอบงานที่แข็งแกร่งกว่า "รันสคริปต์นี้แล้วบอกฉันว่าเกิดอะไรขึ้น" มาก

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

การทำให้คำขอแรกส่งคืน 200 เป็นเพียงจุดเริ่มต้น การทำงานจริงในการผลิตเริ่มต้นหลังจากนั้น

เทมเพลต

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

รูปแบบที่เป็นประโยชน์คือ:

1. เก็บ ID เทมเพลตไว้ในตัวแปรสภาพแวดล้อมหรือการกำหนดค่า
2. ติดป้ายกำกับแต่ละเทมเพลตตามวัตถุประสงค์ สถานที่ และสถานะการอนุมัติ
3. แยกเทมเพลตทดสอบออกจากเทมเพลตแคมเปญจริง
4. จัดทำเอกสารว่าเทมเพลตใดแมปกับการเดินทางของผู้ใช้ใด

Apidog ช่วยได้ที่นี่เพราะคุณสามารถสร้างคำขอตัวอย่างสำหรับแต่ละเทมเพลตที่ได้รับอนุมัติ และเก็บไว้ควบคู่ไปกับคอลเล็กชัน API ที่กว้างขึ้นของคุณ

ผู้ติดต่อ

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

หากคุณสร้างตรรกะการซิงค์ผู้ติดต่อ ให้บันทึกกฎเหล่านี้ตั้งแต่เนิ่นๆ:

• ระบบใดเป็นแหล่งข้อมูลที่เชื่อถือได้
• วิธีการปรับปรุงหมายเลขโทรศัพท์ให้เป็นมาตรฐาน
• วิธีการจัดเก็บสถานะการเลือกเข้าร่วมหรือความยินยอม
• จะเกิดอะไรขึ้นเมื่อผู้ติดต่อเปลี่ยนช่องทาง

สิ่งเหล่านี้ไม่ใช่รายละเอียดที่ต้องแก้ไขในภายหลัง พวกเขาส่งผลกระทบต่อความสามารถในการส่งมอบและการปฏิบัติตามข้อกำหนดตั้งแต่เริ่มต้น

เว็บฮุค

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

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

เอกสารยังอธิบายรูปแบบลายเซ็นว่า v1,{base64_signature} และแนะนำการป้องกันการเล่นซ้ำด้วยกรอบเวลาการประทับเวลาห้านาที

นั่นทำให้คุณมีรายการตรวจสอบการผลิตที่สะอาด:

1. อ่านเนื้อหาคำขอแบบดิบ
2. ยืนยันลายเซ็นก่อนแยกวิเคราะห์
3. ปฏิเสธการประทับเวลาที่ล้าสมัย
4. ประมวลผลเหตุการณ์อย่างไม่ซ้ำซ้อน (idempotently)
5. ยืนยันอย่างรวดเร็วและย้ายงานหนักไปที่งานเบื้องหลัง

นี่คือตัวอย่าง 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 เพื่อจัดเก็บตัวอย่างเพย์โหลดของเว็บฮุคและบันทึกเหตุการณ์ที่คาดไว้ นั่นจะช่วยให้ทีมส่วนหน้า ส่วนหลัง และ QA สามารถปรับแนวคิดรอบวงจรชีวิตของข้อความเดียวกันได้ง่ายขึ้น

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

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

นี่คือความแตกต่างในทางปฏิบัติ:

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

สิ่งนี้มีประโยชน์อย่างน้อยสามสถานการณ์:

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

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

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

เมื่อโฟลว์พื้นฐานทำงานแล้ว การปฏิบัติต่อไปนี้จะทำให้การรวมระบบมีความน่าเชื่อถือมากขึ้น

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

1. เก็บข้อมูลรับรองไว้ในฝั่งเซิร์ฟเวอร์เท่านั้น เอกสารของ Sent เตือนอย่างชัดเจนว่าห้ามเปิดเผยคีย์ API ในโค้ดฝั่งไคลเอ็นต์
2. ติดตาม messageId ในบันทึกแอปพลิเคชันและเครื่องมือสนับสนุนของคุณ
3. แยกเทมเพลตสำหรับ staging และ production
4. ตรวจสอบ webhook ทุกครั้งก่อนประมวลผล
5. ใช้ Apidog environments เพื่อแยกข้อมูลรับรองจริงออกจากข้อมูลรับรองสำหรับการทดสอบ

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

1. การถือว่าการตอบกลับ 200 เป็นผลลัพธ์การส่งมอบสุดท้าย แทนที่จะเป็นจุดเริ่มต้นของวงจรชีวิตเหตุการณ์
2. การ hardcode ID เทมเพลตในหลายบริการ
3. การละเลยการตั้งค่าตัวตนผู้ส่งจนกว่าจะถึงช่วงท้ายของการเปิดตัว
4. การลืมปรับหมายเลขโทรศัพท์ให้เป็นมาตรฐานอย่างสม่ำเสมอ
5. การทดสอบด้วยข้อมูลรับรองจริงในสคริปต์เฉพาะกิจที่ไม่มีใครสามารถตรวจสอบได้

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

หากคำขอไม่ทำงาน ให้ตรวจสอบตามลำดับ:

1. x-api-key ถูกต้องและใช้งานอยู่หรือไม่?
2. เอนด์พอยต์ที่คุณกำลังเรียกตรงกับเวอร์ชันที่แสดงในพื้นที่ทำงาน Sent ของคุณหรือไม่?
3. จำเป็นต้องใช้ x-sender-id สำหรับเส้นทางคำขอนั้นหรือไม่?
4. เทมเพลตได้รับการอนุมัติและพร้อมใช้งานสำหรับช่องทางที่เลือกหรือไม่?
5. คุณกำลังส่งไปยังหมายเลขโทรศัพท์ในรูปแบบที่ถูกต้องหรือไม่?

Apidog ช่วยได้ที่นี่เนื่องจากคุณสามารถเปรียบเทียบคำขอที่ล้มเหลวกับคำขอที่บันทึกไว้ที่ถูกต้องได้ในไม่กี่วินาที

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

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

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

บทสรุป

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

หากคุณต้องการไปได้เร็วขึ้น ให้เริ่มต้นด้วยการสร้างคำขอ Sent ครั้งแรกใน Apidog เพิ่มการยืนยันสำหรับ messageId จากนั้นจัดทำเอกสารสัญญาเว็บฮุคของคุณในพื้นที่ทำงานเดียวกัน ซึ่งจะทำให้คุณมีเส้นทางที่สะอาดขึ้นจากต้นแบบไปสู่การผลิตมากกว่าการพึ่งพาสคริปต์ที่กระจัดกระจายและความรู้แบบปากต่อปาก

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

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

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

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

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

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

เอกสารสาธารณะแสดง x-api-key เป็นส่วนหัวการตรวจสอบสิทธิ์หลัก และตัวอย่างข้อความเริ่มต้นใช้งานยังใช้ x-sender-id ด้วย โปรดตรวจสอบเวอร์ชันเอนด์พอยต์ที่แน่นอนในบัญชี Sent ของคุณก่อนการเปิดตัวจริง เนื่องจากเอกสารแสดงข้อมูลอ้างอิงทั้ง v3 และ v2

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

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

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

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

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

ตรวจสอบลายเซ็น HMAC, ตรวจสอบการประทับเวลา และประมวลผลเหตุการณ์แบบไม่ซ้ำซ้อน เอกสารของ Sent อธิบายถึงส่วนหัวต่างๆ เช่น x-webhook-signature, x-webhook-id และ x-webhook-timestamp สำหรับการตรวจสอบ

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

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