Quickstart
From API key to traceable message.
The first Dugble integration should prove three things: your request is accepted, your message can be traced, and your backend receives delivery events.
Step 01
Create a workspace
Keep API keys, senders, logs, and webhooks grouped by product or environment.
Step 02
Generate an API key
Use server-side keys for authenticated email and SMS requests.
DUGBLE_API_KEY=sk_live_51ac9f2e... DUGBLE_ENV=production
Step 03
Send a test SMS
Start with an OTP payload and confirm you receive a message_id back.
curl https://api.dugble.com/v1/messages \ -H "Authorization: Bearer $DUGBLE_API_KEY" \ -d channel="sms" -d to="+233531184325" \ -d template="login_otp"
{
"message_id": "msg_9c41af",
"status": "queued",
"channel": "sms",
"created_at": "2026-07-22T09:14:02Z"
}Add an idempotency_key to this request. Retrying a failed network call then won't send a second OTP.
Step 04
Add a webhook
Point Dugble at an endpoint that can receive message.delivered and message.failed.
POST /webhooks/dugble X-Dugble-Event: message.delivered X-Dugble-Signature: t=1721642042,v1=5f3d8c9e...
HTTP/1.1 200 OK
Return a 2xx within a few seconds. Anything slower or a non-2xx queues a retry.
Step 05
Check logs
Search by message_id or recipient to confirm status, provider response, and webhook attempts.
dugble logs --message-id msg_9c41af > queued → sent → delivered (812ms)
The same trace is one click away in the dashboard's log table, not just the CLI.
What success looks like
After the first test message, you should have a message ID, an initial queued state, a searchable log entry, and a webhook event path ready for delivery updates.
- message_id returned on accept
- queued status in the response
- log entry searchable by ID
- webhook path ready for events
Stuck on a step? The full API reference has request and response examples for every endpoint.
Send your first message in the next five minutes.
Create a workspace, generate an API key, and watch the delivery event come back in the dashboard.