Rackwave exposes RESTful APIs for each platform — MigoSMTP and Telnxo — allowing you to integrate email delivery, SMS, voice calls, and WhatsApp messaging directly into your applications, scripts, and workflows. This article provides an overview of the available APIs, their design principles, and what you can build with them.
Available APIs
| Platform | API Name | Base URL | Primary Use |
|---|---|---|---|
| MigoSMTP | Email API | https://api.migosmtp.com/v1 | Send email, manage templates, domains, suppressions, retrieve logs |
| Telnxo | CPaaS API | https://api.telnxo.com/v1 | Send SMS, make voice calls, send WhatsApp messages, manage templates, retrieve logs |
Independent APIs: MigoSMTP and Telnxo are separate platforms with separate APIs, separate base URLs, and separate API keys. An API key generated in MigoSMTP cannot authenticate requests to the Telnxo API and vice versa.
API Design Principles
Both APIs follow a consistent set of design principles that make them predictable and easy to integrate:
| Principle | Implementation |
|---|---|
| REST architecture | Standard HTTP methods — GET, POST, PUT, DELETE, PATCH — mapped to resource operations |
| JSON everywhere | All request bodies and response payloads use JSON. Always set Content-Type: application/json |
| Bearer token auth | All requests are authenticated via an API key passed in the Authorization: Bearer header |
| Consistent error format | All errors return a standard JSON body with error, message, and code fields |
| Predictable HTTP status codes | 2xx for success, 4xx for client errors, 5xx for server errors — see status code table below |
| Versioned endpoints | API version included in the base URL (/v1/). Breaking changes are introduced in new versions with a deprecation period for old versions |
| Idempotency keys | Supported on sending endpoints via the X-Idempotency-Key header to prevent duplicate sends on retry |
| HTTPS only | All API traffic must use HTTPS (TLS 1.2 minimum, TLS 1.3 recommended). HTTP requests are rejected. |
HTTP Status Codes Reference
| Code | Meaning | Common Cause |
|---|---|---|
| 200 | OK — request succeeded | Standard success response for GET requests |
| 201 | Created — resource created successfully | Message queued, template created, domain added |
| 202 | Accepted — request received and queued | Bulk send accepted for processing |
| 204 | No Content — success with no body | Successful DELETE operations |
| 400 | Bad Request — invalid input | Missing required fields, invalid email format, malformed JSON |
| 401 | Unauthorized — authentication failed | Missing, invalid, or revoked API key |
| 402 | Payment Required — account suspended | Subscription expired or invoice overdue |
| 403 | Forbidden — insufficient permissions | API key scope does not permit this operation |
| 404 | Not Found — resource does not exist | Invalid message ID, template ID, or domain ID |
| 409 | Conflict — duplicate resource | Domain already exists, duplicate idempotency key |
| 422 | Unprocessable Entity — validation error | Field value fails validation (e.g. invalid phone number format) |
| 429 | Too Many Requests — rate limit exceeded | API request rate or sending quota exceeded |
| 500 | Internal Server Error — platform error | Unexpected platform-side error; retry with exponential backoff |
| 503 | Service Unavailable — temporary outage | Platform maintenance or high load; retry after a short delay |
Standard Error Response Format
All API errors return a consistent JSON body:
{
"success": false,
"error": "validation_error",
"message": "The 'to' field must be a valid email address.",
"code": 422,
"field": "to"
}
| Field | Description |
|---|---|
success |
Always false on error responses |
error |
Machine-readable error code string (e.g. authentication_failed, quota_exceeded) |
message |
Human-readable description of the error |
code |
HTTP status code (mirrors the response status) |
field |
The specific request field that caused a validation error (present on 422 errors only) |
What You Can Build with the APIs
- Transactional email pipeline — OTPs, welcome emails, password resets, order confirmations sent programmatically via MigoSMTP Email API.
- Multi-channel notification system — trigger email + SMS + WhatsApp from a single backend event via MigoSMTP + Telnxo APIs.
- Custom CRM integration — sync suppression lists, delivery status, and engagement data with your own CRM or database.
- Bulk communication workflows — upload contacts, create templates, schedule and dispatch bulk campaigns via API.
- Delivery monitoring dashboard — pull real-time delivery stats via Reporting API and display in your own internal dashboards.
- Webhook processing pipeline — receive delivery events in real time and update your application's message status records automatically.