Cara Kirim SMS dan WhatsApp Lebih Cepat dengan API Sent.dm

TL;DR / Jawaban Singkat

API Sent.dm memberikan Anda satu titik integrasi untuk pengiriman pesan bisnis di seluruh SMS dan WhatsApp. Jika Anda menggabungkan Sent dengan Apidog, Anda dapat menyimpan kredensial Anda di lingkungan, menguji permintaan tanpa menulis skrip sekali pakai, memvalidasi payload webhook, dan mendokumentasikan alur kerja pengiriman pesan Anda di satu tempat.

Pendahuluan

Sebagian besar proyek pengiriman pesan melambat di tempat yang sama: API itu sendiri tidak sulit, tetapi detail operasional menumpuk dengan cepat. Anda memerlukan kunci API, identitas pengirim, ID templat, keamanan webhook, aturan saluran, dan cara yang bersih untuk menguji semua itu tanpa mengirim pesan nyata secara membabi buta.

Itulah mengapa Sent.dm menarik. Sent memposisikan dirinya sebagai API pengiriman pesan terpadu untuk SMS dan saluran berbasis aplikasi seperti WhatsApp, dengan logika perutean dan pengiriman ditangani di balik satu antarmuka yang menghadap pengembang. Berdasarkan dokumen publik Sent yang ditinjau pada 26 Maret 2026, platform ini mencakup verifikasi akun, pengaturan saluran, pengiriman berbasis templat, kontak, kejadian webhook, dan arena bermain dasbor untuk pengujian.

tombol

Apa yang Diselesaikan oleh API Sent.dm

Sent.dm dibangun untuk tim yang ingin menjangkau pengguna di lebih dari satu saluran pengiriman pesan tanpa harus memelihara integrasi terpisah untuk setiap penyedia. Alih-alih menyatukan API SMS, orientasi WhatsApp, format payload khusus saluran, dan pemantauan pengiriman sendiri, Sent mengabstraksi kompleksitas itu menjadi satu platform.

Dari dokumen resmi, cerita produknya lugas:

• Satu URL dasar API untuk alur kerja pengiriman pesan
• Autentikasi berbasis header dengan x-api-key
• Model identitas pengirim menggunakan x-sender-id
• Pengiriman pesan keluar berbasis templat
• Manajemen kontak dan audiens
• Webhook untuk kejadian pengiriman dan templat
• Konsep perutean cerdas dan failover di lapisan platform

Kombinasi itu penting karena sistem pengiriman pesan jarang hanya "mengirim teks dan melanjutkan." Anda juga membutuhkan:

• Struktur payload yang konsisten
• Cara yang aman untuk menggunakan kembali templat
• Pelacakan kejadian untuk pesan yang terkirim, gagal, atau antrean
• Alur kerja pengujian yang menjaga rahasia agar tidak terekspos di kode frontend
• Dokumentasi yang dapat benar-benar digunakan oleh pengembang dan rekan kerja QA Anda

Berikut adalah tantangan yang lebih besar dalam praktiknya:

Aplikasi -> API Pesan -> Aturan Saluran -> Kejadian Pengiriman -> Logika Coba Lagi / Status

Jika setiap bagian berada di alat yang berbeda, proses debug menjadi lambat. Salah satu cara termudah untuk mencegah hal itu terjadi adalah dengan memodelkan seluruh alur dalam platform API seperti Apidog sejak awal.

Bagaimana API Sent.dm Bekerja

Dokumen publik Sent menggambarkan platform ini sebagai lapisan middleware cerdas antara aplikasi Anda dan saluran pengiriman pesan hilir. Janjinya sederhana: aplikasi Anda mengirim satu permintaan, dan Sent memilih jalur pengiriman terbaik berdasarkan logika perutean, konteks penerima, dan ketersediaan saluran.

Bagi pengembang, bagian terpenting adalah urutan penyiapan dan model kredensial.

1. Penyiapan akun dan kepatuhan

Alur memulai resmi dimulai dengan pembuatan akun, verifikasi KYC, dan penyiapan bisnis. Itu bukan pekerjaan rumah opsional. Produk pengiriman pesan menyentuh aturan kepatuhan, reputasi pengirim, dan batasan regional, sehingga Sent menjadikan verifikasi akun sebagai bagian dari jalur orientasi.

2. Penyiapan saluran

Dokumen Sent memandu Anda dalam memilih nomor telepon dan menghubungkan WhatsApp Business. Dokumen merekomendasikan penggunaan nomor yang sama untuk SMS dan WhatsApp agar identitas merek Anda tetap konsisten di seluruh saluran.

3. Templat

Templat adalah bagian inti dari alur kerja. Dalam panduan memulai, Sent meminta Anda membuat templat sebelum mengirim permintaan API pertama Anda. Itu adalah sinyal yang baik bahwa pengiriman pesan berbasis templat bukanlah kasus tepi di sini. Ini adalah bagian dari jalur default.

4. Kredensial API

Dokumen menunjukkan dua kredensial:

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

Referensi API v3 menyoroti x-api-key sebagai header autentikasi yang diperlukan. Contoh memulai juga mencakup x-sender-id untuk permintaan pesan. Saat Anda mengimplementasikannya dalam produksi, verifikasi persyaratan header yang tepat terhadap ruang kerja dan versi endpoint Anda saat ini di dasbor Sent, karena dokumen menampilkan tampilan referensi v3 dan contoh pesan v2.

5. Permintaan pesan

Panduan memulai menunjukkan permintaan ke:

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

dengan payload JSON berbentuk seperti ini:

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

Itu memberi tahu Anda sesuatu yang penting tentang target implementasi pertama: jalur tercepat bukanlah membangun layanan orkestrasi omnichannel raksasa. Ini adalah pengaturan pengiriman berbasis templat dengan benar, kemudian memperluas alur kerja setelah Anda dapat mengamati perilaku permintaan dan pengiriman secara andal.

Kirim Permintaan API Sent.dm Pertama Anda

Mari kita bangun permintaan pertama dengan cara yang mudah diuji dan mudah dipelihara.

Contoh 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"
 }'

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

Contoh 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())

Menurut dokumen memulai, respons yang berhasil mengembalikan HTTP 200 dan messageId. messageId itulah nilai yang ingin Anda tangkap dalam pengujian Apidog, log aplikasi, alur kerja dukungan, dan rekonsiliasi webhook.

Uji API Sent.dm di Apidog

Di sinilah Apidog menjadi lebih dari sekadar pelari permintaan. API pengiriman pesan lebih mudah dikerjakan ketika permintaan, variabel, pernyataan pengujian, dokumen, dan serah terima tim semuanya berada di satu tempat.

Langkah 1: Buat lingkungan Sent

Di Apidog, buat lingkungan dengan variabel seperti:

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

Menggunakan variabel lingkungan memberi Anda tiga manfaat langsung:

1. Anda menghindari pengodean rahasia produksi secara permanen dalam contoh.
2. Anda dapat beralih antara akun sandbox, staging, dan live lebih cepat.
3. Rekan tim dapat menggunakan kembali koleksi yang sama dengan nilai aman mereka sendiri.

Langkah 2: Bangun permintaan sekali saja

Buat permintaan baru di Apidog:

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

• Metode: POST
• URL: {{base_url}}/v2/messages/phone
• Header:
• Isi:

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

Ini sudah lebih baik daripada pengujian terminal sekali pakai karena tim Anda dapat memeriksa bentuk payload yang tepat, model autentikasi, dan respons yang diharapkan di satu tempat.

Langkah 3: Tambahkan pernyataan (assertions)

Di Apidog, tambahkan pengujian yang memvalidasi jalur keberhasilan.

Contoh pemeriksaan:

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

Pemeriksaan ini membantu Anda menangkap kesalahan halus dengan cepat. Jika permintaan berhenti mengembalikan ID pesan setelah perubahan API, rotasi kredensial, atau masalah templat, Anda akan segera melihatnya.

Langkah 4: Ubah menjadi skenario

Apidog menjadi lebih berguna ketika Anda beralih dari permintaan tunggal ke alur kerja:

1. Kirim pesan
2. Simpan messageId yang dikembalikan
3. Kueri status hilir jika pengaturan Anda mengekspos alur tersebut
4. Bandingkan kejadian pesan yang diterima melalui webhook

Itu adalah tingkat pengujian API yang tepat untuk sistem pengiriman pesan karena satu POST yang berhasil tidak berarti alur bisnis Anda sehat. Anda juga peduli tentang persetujuan, pengiriman, percobaan ulang, dan konsistensi kejadian.

Langkah 5: Tambahkan contoh webhook ke koleksi yang sama

Setelah permintaan kirim Anda berfungsi, tambahkan contoh yang disimpan untuk kejadian webhook yang diharapkan akan diterima oleh tim Anda. Itu memberi Anda satu koleksi yang mencakup permintaan keluar dan penanganan kejadian masuk.

Misalnya, Anda dapat menyimpan contoh payload webhook dan mendokumentasikan bidang seperti:

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

Ini akan membuahkan hasil dengan cepat. Insinyur backend dapat membandingkan payload live dengan contoh yang disimpan, QA dapat memvalidasi logika penanganan kejadian, dan tim dukungan dapat memahami arti status pesan tanpa menggali log.

Langkah 6: Publikasikan dokumen internal

Jika tim Anda memiliki insinyur backend, QA, dukungan, dan pemangku kepentingan produk yang menyentuh alur pengiriman pesan yang sama, lapisan dokumentasi Apidog menghemat waktu. Daripada membagikan kumpulan cuplikan cURL yang lepas di obrolan, Anda dapat mempublikasikan referensi internal yang bersih yang mencakup:

• Header yang diperlukan
• Contoh payload
• Respons kesalahan
• Contoh kejadian webhook
• Catatan lingkungan

Itu adalah serah terima yang jauh lebih kuat daripada "jalankan skrip ini dan beri tahu saya apa yang terjadi."

Tangani Templat, Kontak, dan Webhook dengan Cara yang Benar

Mendapatkan permintaan pertama untuk mengembalikan 200 hanyalah permulaan. Pekerjaan produksi yang sebenarnya dimulai setelah itu.

Templat

Alur orientasi Sent sangat menekankan templat, terutama untuk pesan terkait WhatsApp. Itu berarti implementasi API Anda harus memperlakukan templat sebagai konten berversi, bukan hanya ID yang disalin ke file sekali dan dilupakan.

Pola praktis adalah:

1. Simpan ID templat di variabel lingkungan atau konfigurasi
2. Beri label setiap templat berdasarkan tujuan, lokal, dan status persetujuan
3. Pisahkan templat pengujian dari templat kampanye live
4. Dokumentasikan templat mana yang dipetakan ke perjalanan pengguna mana

Apidog membantu di sini karena Anda dapat membuat contoh permintaan untuk setiap templat yang disetujui dan menyimpannya di samping koleksi API Anda yang lebih luas.

Kontak

Dokumen Sent menampilkan kontak sebagai area fitur kelas satu. Meskipun aplikasi Anda sudah menyimpan pengguna secara internal, objek kontak di platform pengiriman pesan berguna untuk operasi tingkat audiens, penargetan templat, dan riwayat komunikasi.

Jika Anda membangun logika sinkronisasi kontak, dokumentasikan aturan ini sejak awal:

• Sistem mana yang merupakan sumber kebenaran
• Bagaimana nomor telepon dinormalisasi
• Bagaimana status keikutsertaan atau persetujuan disimpan
• Apa yang terjadi ketika kontak mengubah saluran

Itu bukanlah detail yang harus dibersihkan nanti. Itu memengaruhi kemampuan pengiriman dan kepatuhan sejak awal.

Webhook

Dokumentasi webhook Sent adalah salah satu bagian terpenting dari platform untuk penggunaan produksi yang sebenarnya. Dokumen tersebut menjelaskan verifikasi tanda tangan HMAC-SHA256 dengan header yang mencakup:

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

Dokumen tersebut juga menjelaskan format tanda tangan sebagai v1,{base64_signature} dan merekomendasikan perlindungan replay dengan jendela stempel waktu lima menit.

Itu memberi Anda daftar periksa produksi yang bersih:

1. Baca isi permintaan mentah
2. Verifikasi tanda tangan sebelum menguraikan
3. Tolak stempel waktu yang kadaluarsa
4. Proses kejadian secara idempoten
5. Akui dengan cepat dan pindahkan pekerjaan berat ke pekerjaan latar belakang

Berikut adalah contoh Express yang ringkas:

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

Gunakan Apidog untuk menyimpan contoh payload webhook dan mendokumentasikan kejadian yang diharapkan. Itu membuatnya lebih mudah bagi tim frontend, backend, dan QA untuk menyelaraskan di sekitar siklus hidup pesan yang sama.

Mengapa Apidog Cocok dengan Alur Kerja Ini

Sent.dm memberi Anda lapisan pengiriman pesan. Apidog memberi Anda lapisan alur kerja di sekitar lapisan pengiriman pesan itu.

Berikut adalah perbedaan praktisnya:

Jika tim Anda mengevaluasi Sent untuk pengiriman pesan aplikasi, Apidog mencakup lapisan yang tidak coba dicapai Sent: desain API kolaboratif, pengujian, debugging, perencanaan mock, dan dokumentasi dalam satu ruang kerja.

Itu berguna dalam setidaknya tiga situasi:

• Anda sedang mengorientasi beberapa pengembang dan membutuhkan koleksi permintaan yang dapat dibagikan
• Anda ingin QA memvalidasi API pengiriman pesan tanpa menulis skrip kustom
• Anda membutuhkan tempat yang dapat diulang untuk menguji perubahan versi, templat baru, atau payload webhook

Unduh Apidog secara gratis untuk menguji permintaan Sent.dm, menyimpan lingkungan pengiriman pesan dengan aman, dan mengubah panggilan API pertama Anda yang berhasil menjadi alur kerja tim yang dapat digunakan kembali.

tombol

Tips Lanjutan dan Kesalahan Umum

Setelah alur dasar berfungsi, praktik-praktik ini membuat integrasi lebih andal.

Praktik terbaik

1. Jaga kredensial hanya di sisi server. Dokumen Sent secara eksplisit memperingatkan agar tidak mengekspos kunci API dalam kode sisi klien.
2. Lacak messageId di log aplikasi dan alat dukungan Anda.
3. Pisahkan templat staging dan produksi.
4. Verifikasi setiap webhook sebelum memprosesnya.
5. Gunakan lingkungan Apidog untuk mengisolasi kredensial live dari kredensial pengujian.

Kesalahan umum yang harus dihindari

1. Memperlakukan respons 200 sebagai hasil pengiriman akhir alih-alih awal siklus hidup kejadian
2. Mengodekan ID templat secara permanen di beberapa layanan
3. Mengabaikan penyiapan identitas pengirim sampai akhir peluncuran
4. Lupa untuk menormalisasi nomor telepon secara konsisten
5. Menguji dengan kredensial nyata dalam skrip ad hoc yang tidak dapat diperiksa oleh orang lain

Petunjuk pemecahan masalah

Jika permintaan tidak berfungsi, periksa ini secara berurutan:

1. Apakah x-api-key valid dan aktif?
2. Apakah endpoint yang Anda panggil cocok dengan versi yang ditampilkan di ruang kerja Sent Anda?
3. Apakah x-sender-id diperlukan untuk jalur permintaan itu?
4. Apakah templat disetujui dan tersedia untuk saluran yang dipilih?
5. Apakah Anda mengirim ke nomor telepon dalam format yang benar?

Apidog membantu di sini karena Anda dapat membandingkan permintaan yang gagal dengan permintaan yang disimpan yang diketahui baik dalam hitungan detik.

Alternatif dan Perbandingan Sent.dm

Jika Anda mengevaluasi Sent.dm, Anda mungkin juga melihat integrasi penyedia langsung, platform komunikasi yang lebih luas, atau klien API yang akrab seperti Postman untuk pengujian sehari-hari. Perbedaan utamanya adalah kontrol versus kesederhanaan, dan lapisan pengujian sama pentingnya dengan lapisan pengiriman.

Untuk tim yang peduli dengan kecepatan pengembang, pengaturan terbaik seringkali bukan "pilih satu alat untuk semuanya." Ini adalah menggabungkan platform pengiriman dengan lapisan kolaborasi API yang kuat. Jika Anda sudah menggunakan Postman, alasan terkuat untuk melihat Apidog di sini bukanlah pengiriman permintaan dasar. Ini adalah memiliki lingkungan, dokumen yang disimpan, pernyataan, perencanaan mock, dan serah terima tim dalam satu ruang kerja.

Kesimpulan

Sent.dm adalah API pengiriman pesan yang berguna untuk tim yang menginginkan satu platform untuk SMS dan WhatsApp alih-alih integrasi saluran yang terpisah. Kemenangan terbesar bukan hanya karena Anda dapat mengirim pesan. Ini adalah karena Anda dapat menguji dan membangun di sekitar templat, identitas pengirim, kontak, dan webhook dengan cara yang lebih terstruktur.

Jika Anda ingin bergerak lebih cepat, mulailah dengan membangun permintaan Sent pertama di Apidog, tambahkan pernyataan untuk messageId, lalu dokumentasikan kontrak webhook Anda di ruang kerja yang sama. Itu memberi Anda jalur yang lebih bersih dari prototipe ke produksi daripada mengandalkan skrip yang tersebar dan pengetahuan lisan.

tombol

FAQ

Untuk apa API Sent.dm digunakan?

API Sent.dm digunakan untuk pengiriman pesan bisnis di seluruh saluran seperti SMS dan WhatsApp melalui satu integrasi. Berdasarkan dokumen resmi, ini mendukung penyiapan pengirim, templat, kontak, dan penanganan kejadian berbasis webhook.

Apakah Sent.dm mendukung WhatsApp dan SMS dalam satu API?

Ya. Sent memposisikan platform sebagai API pengiriman pesan terpadu yang mengabstraksi kompleksitas khusus saluran di balik satu integrasi pengembang. Dokumen orientasi juga merekomendasikan penggunaan nomor telepon yang sama di seluruh SMS dan WhatsApp.

Header apa yang saya butuhkan untuk permintaan API Sent.dm?

Dokumen publik menunjukkan x-api-key sebagai header autentikasi inti, dan contoh pesan memulai juga menggunakan x-sender-id. Periksa versi endpoint yang tepat di akun Sent Anda sebelum peluncuran produksi karena dokumen menampilkan referensi v3 dan v2.

Apakah saya membutuhkan templat sebelum mengirim pesan dengan Sent.dm?

Untuk alur memulai, ya. Panduan orientasi Sent memandu Anda dalam membuat templat dan kemudian mengirim pesan pertama dengan templateId.

Bagaimana cara menguji API Sent.dm tanpa menulis skrip kustom?

Apidog sangat cocok untuk ini. Anda dapat menyimpan kredensial Sent Anda sebagai variabel lingkungan, menyimpan permintaan pesan, menambahkan pernyataan, membangun skenario multi-langkah, mendokumentasikan payload webhook, dan mempublikasikan dokumentasi API internal untuk seluruh tim Anda.

Bagaimana seharusnya saya mengamankan webhook Sent.dm?

Verifikasi tanda tangan HMAC, validasi stempel waktu, dan proses kejadian secara idempoten. Dokumen Sent menjelaskan header seperti x-webhook-signature, x-webhook-id, dan x-webhook-timestamp untuk verifikasi.

Apakah Sent.dm cukup sendiri untuk alur kerja API tim?

Ini mencakup platform pengiriman pesan itu sendiri, tetapi sebagian besar tim masih membutuhkan alat API kolaboratif untuk pengujian, dokumentasi, dan validasi berulang. Di situlah Apidog menambahkan nilai.