How to Send SMS and WhatsApp Messages Faster using Sent.dm API ?

TL;DR / Quick Answer

The Sent.dm API gives you one integration point for business messaging across SMS and WhatsApp. Pair it with Apidog to store credentials in environments, test requests without throwaway scripts, validate webhook payloads, and document your messaging workflow in one place.

Try Apidog today

Introduction

Messaging integrations usually get difficult after the first API call. You need API keys, sender identity, template IDs, webhook verification, channel rules, delivery tracking, and a safe way to test without blindly sending real messages.

Sent.dm is positioned as a unified messaging API for SMS and app-based channels like WhatsApp. Based on Sent's public docs reviewed on March 26, 2026, the platform includes account verification, channel setup, template-based sending, contacts, webhook events, and a dashboard playground for testing.

Apidog is useful alongside Sent because it gives your team a repeatable API workflow: import or model the Sent API, create reusable environments for x-api-key and x-sender-id, test message creation, validate webhook examples, and publish internal docs.

What the Sent.dm API Solves

Sent.dm is built for teams that want to reach users across multiple messaging channels without maintaining separate integrations for each provider. Instead of wiring together SMS APIs, WhatsApp onboarding, channel-specific payload formats, and delivery monitoring yourself, Sent abstracts that complexity behind one developer-facing platform.

From the official docs, the Sent.dm workflow includes:

• One API base URL for messaging workflows
• Header-based authentication with x-api-key
• A sender identity model using x-sender-id
• Template-driven outbound messaging
• Contacts and audience management
• Webhooks for delivery and template events
• Routing and failover concepts in the platform layer

That matters because production messaging is rarely just:

send text -> done

A real workflow usually looks more like this:

Application
  -> Message API
  -> Channel rules
  -> Delivery events
  -> Retry / status logic
  -> Support and audit trail

If each step lives in a different script, dashboard, or chat thread, debugging gets slow. A better approach is to model the whole flow in an API workspace like Apidog from the beginning.

How the Sent.dm API Works

Sent's public docs describe the platform as middleware between your app and downstream messaging channels. Your application sends one request, and Sent handles the delivery path based on routing logic, recipient context, and channel availability.

For implementation, focus on these pieces first.

1. Account and compliance setup

The getting-started flow begins with:

• Account creation
• KYC verification
• Business setup

This is not just administrative work. Messaging APIs are tied to compliance, sender reputation, regional restrictions, and channel approval processes.

2. Channel setup

Sent's docs walk through choosing a phone number and connecting WhatsApp Business. The docs recommend using the same number for SMS and WhatsApp so the sender identity stays consistent across channels.

3. Templates

Templates are part of the default workflow. In the getting-started guide, Sent has you create a template before sending the first API request.

Treat templates as application configuration, not hardcoded constants. You will likely need separate templates for environments, locales, use cases, and approval states.

4. API credentials

The docs show these request headers:

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

The v3 API reference highlights x-api-key as the required authentication header. The getting-started examples also include x-sender-id for message requests.

Before production rollout, verify the exact header requirements against your current workspace and endpoint version in the Sent dashboard because the docs surface both a v3 reference view and v2 message examples.

5. Message request

The getting-started guide shows this endpoint:

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

With this JSON payload:

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

The practical first milestone is simple: get template-based sending working, capture the returned messageId, then use webhooks to observe the delivery lifecycle.

Send Your First Sent.dm API Request

Start with a minimal request that is easy to test, log, and repeat.

cURL example

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 example

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 example

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

According to the getting-started docs, a successful response returns HTTP 200 and a messageId.

Capture that messageId in:

• Application logs
• Apidog test variables
• Support tooling
• Webhook reconciliation logic

Test the Sent.dm API in Apidog

Apidog is useful here because the request, variables, assertions, examples, and documentation can live in one shared workspace.

Step 1: Create a Sent environment

Create an Apidog environment with variables like:

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

Using environment variables helps you:

• Avoid hardcoding secrets
• Switch between test and production values
• Share the same collection with teammates
• Keep examples readable without exposing credentials

Step 2: Build the message request

Create a new request in 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}}"
}

Now your team has one inspectable request instead of several local scripts with slightly different headers or payloads.

Step 3: Add assertions

Add tests for the success path.

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

These checks catch common regressions quickly, such as:

• Invalid credentials
• Incorrect sender ID
• Template changes
• Endpoint version mismatch
• Response shape changes

Step 4: Store the messageId

If your Apidog workflow supports variable extraction, store the returned messageId for later steps.

Example:

const json = pm.response.json();

if (json.messageId) {
  pm.environment.set("message_id", json.messageId);
}

You can then reuse {{message_id}} in follow-up requests or webhook validation notes.

Step 5: Turn the request into a scenario

A useful messaging API scenario is more than one POST request.

Model a workflow like this:

1. Send a template message.
2. Capture the returned messageId.
3. Query downstream status if your Sent setup exposes that flow.
4. Compare received webhook events against expected examples.
5. Document expected terminal states such as delivered, failed, or queued.

This is a better production test because a successful API response does not guarantee final delivery.

Step 6: Add webhook examples

After the send request works, add saved webhook payload examples to the same collection.

Example webhook payload:

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

This gives backend, QA, and support teams a shared reference for what your application expects to receive.

Step 7: Publish internal docs

Use the Apidog documentation layer to publish internal docs for:

• Required headers
• Environment variables
• Example request bodies
• Success responses
• Error responses
• Webhook event examples
• Operational notes

That is easier to maintain than cURL snippets scattered across tickets and chat messages.

Handle Templates, Contacts, and Webhooks Correctly

Getting the first 200 response is only the beginning. The production integration should handle templates, contacts, and webhooks deliberately.

Templates

Sent's onboarding flow emphasizes templates, especially for WhatsApp-related messaging.

Use a simple template management pattern:

• Store template IDs in environment variables or server-side config.
• Label templates by purpose, locale, and approval status.
• Separate test templates from production templates.
• Document which template maps to which user journey.
• Avoid copying template IDs into multiple services.

In Apidog, create example requests for each approved template so the payload and use case are visible to the team.

Contacts

The Sent docs surface contacts as a first-class feature area. Even if your application already stores users, contact objects in the messaging platform can support audience operations, template targeting, and communication history.

Document these rules before building contact sync:

• Which system is the source of truth
• How phone numbers are normalized
• Where opt-in or consent state is stored
• What happens when a user changes channels
• How duplicates are handled

These decisions affect deliverability, compliance, and debugging.

Webhooks

Sent's webhook documentation describes HMAC-SHA256 signature verification with these headers:

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

The docs also describe the signature format as:

v1,{base64_signature}

They recommend replay protection with a five-minute timestamp window.

Use this production checklist:

• Read the raw request body.
• Verify the signature before parsing JSON.
• Reject stale timestamps.
• Process events idempotently.
• Return a fast 2xx response.
• Move heavy work to background jobs.

Here is a compact Express example:

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

  if (!signature || !webhookId || !timestamp || !secret) {
    return res.status(400).send("Missing webhook verification data");
  }

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

Use Apidog to store webhook examples and document expected events. This keeps frontend, backend, QA, and support aligned on the same message lifecycle.

Why Apidog Fits This Workflow

Sent.dm provides the messaging layer. Apidog provides the workflow layer around testing, debugging, documentation, and team collaboration.

Task	Sent.dm	Apidog
Send SMS and WhatsApp messages	Yes	Tests the API requests
Manage templates and sender setup	Yes	Documents and validates related requests
Test authenticated requests	Basic playground support	Request builder, environments, assertions, scenarios
Share API docs with the team	Platform docs	Team-facing collections and generated docs
Debug request and response flow	Partial	Repeatable inspection and collaboration
Build end-to-end test scenarios	Messaging-focused	Multi-step API workflow testing

This pairing is useful when:

• Multiple developers need the same request collection.
• QA needs to validate messaging APIs without custom scripts.
• You need a repeatable way to test new templates.
• You want webhook examples documented next to outbound requests.
• You need cleaner handoff between backend, QA, support, and product.

Advanced Tips and Common Mistakes

Once the basic flow works, use these practices to make the integration more reliable.

Best practices

• Keep Sent credentials server-side only.
• Store API keys and sender IDs in environment variables.
• Track messageId in logs and support tools.
• Separate staging and production templates.
• Verify every webhook before processing it.
• Make webhook processing idempotent.
• Use Apidog environments to isolate live credentials from test credentials.

Common mistakes to avoid

• Treating a 200 response as final delivery confirmation
• Hardcoding template IDs in multiple services
• Ignoring sender identity setup until late in rollout
• Forgetting to normalize phone numbers consistently
• Testing with real credentials in scripts no one else can inspect
• Parsing webhook JSON before verifying the raw request signature

Troubleshooting checklist

If a request fails, check these in order:

1. Is x-api-key valid and active?
2. Does the endpoint version match your Sent workspace?
3. Is x-sender-id required for this request path?
4. Is the template approved and available for the chosen channel?
5. Is the recipient phone number in the expected format?
6. Are you using the correct environment values?
7. Does the response body contain a useful error message?

In Apidog, compare the failing request against a known-good saved request to identify header, body, or environment differences quickly.

Sent.dm Alternatives and Comparisons

If you are evaluating Sent.dm, you may also be comparing direct-provider integrations, broader communications platforms, or API clients like Postman.

The main tradeoff is control versus simplicity. The testing and collaboration layer matters too.

Option	Strength	Tradeoff
Direct SMS + WhatsApp providers	Fine-grained control	More integration and maintenance work
Twilio-style communications stack	Broad ecosystem	More moving parts for multi-channel orchestration
Sent.dm	Unified messaging workflow with channel abstraction	You depend on Sent's platform conventions and docs structure
Sent.dm + Postman	Familiar request testing flow	Documentation, design, and workflow collaboration can stay fragmented
Sent.dm + Apidog	Unified messaging plus API testing, documentation, and collaboration	Two tools instead of one

For developer speed, the best setup is often not one tool for everything. It is a delivery platform plus a strong API collaboration layer.

If you already use Postman, the reason to evaluate Apidog here is not basic request sending. It is having environments, saved docs, assertions, mock planning, and team handoff in one workspace.

Conclusion

Sent.dm is useful for teams that want one platform for SMS and WhatsApp instead of separate channel integrations. The implementation work is not only sending a message. You also need to manage templates, sender identity, contacts, delivery events, and webhook security.

A practical rollout path looks like this:

1. Configure Sent account, sender, channel, and template setup.
2. Build the first POST /v2/messages/phone request in Apidog.
3. Store credentials in environment variables.
4. Assert that the response returns 200 and includes messageId.
5. Save webhook examples in the same workspace.
6. Document the full messaging lifecycle for the team.

That gives you a cleaner path from prototype to production than scattered scripts and tribal knowledge.

FAQ

What is the Sent.dm API used for?

The Sent.dm API is used for business messaging across channels like SMS and WhatsApp through a single integration. Based on the official docs, it supports sender setup, templates, contacts, and webhook-based event handling.

Does Sent.dm support WhatsApp and SMS in one API?

Yes. Sent positions the platform as a unified messaging API that abstracts channel-specific complexity behind one developer integration. The onboarding docs also recommend using the same phone number across SMS and WhatsApp.

Which headers do I need for Sent.dm API requests?

The public docs show x-api-key as the core authentication header, and the getting-started message examples also use x-sender-id. Check the exact endpoint version in your Sent account before production rollout because the docs surface both v3 and v2 references.

Do I need templates before sending messages with Sent.dm?

For the getting-started flow, yes. Sent's onboarding guide walks through creating a template and then sending the first message with a templateId.

How do I test the Sent.dm API without writing custom scripts?

Use Apidog to store Sent credentials as environment variables, save message requests, add assertions, build multi-step scenarios, document webhook payloads, and publish internal API documentation for your team.

How should I secure Sent.dm webhooks?

Verify the HMAC signature, validate the timestamp, and process events idempotently. Sent's docs describe headers such as x-webhook-signature, x-webhook-id, and x-webhook-timestamp for verification.

Is Sent.dm enough on its own for team API workflows?

Sent.dm covers the messaging platform itself. Most teams still need a collaborative API workspace for testing, documentation, and repeated validation. That is where Apidog adds value.