MessageFlow Developer API

1. Create a project.
2. Add WhatsApp 1–5 sender profile(s).
3. Connect each sender with Official Meta Cloud API or Scan QR — Linked Device.
4. Generate a project API key.
5. Run Launch Readiness and send a connection test.
6. Integrate the REST endpoints from your backend.
7. Optionally configure signed customer webhooks.

Production base URL: https://sms.adarshrupa.in/api/v1

Use X-API-Key or a Bearer token containing the project API key.

POST /api/v1/messages/send
X-API-Key: mf_live_your_secret_key
Content-Type: application/json

The full API-key secret is shown only when created/rotated. Store it in a server-side secret manager or environment variable.

Official Meta Cloud API

Provider credentials are stored encrypted. The sender is marked connected only after verification. Configure the callback URL shown in the dashboard for Meta delivery/read events.

Scan QR — Linked Device

Scan the QR using the phone's Linked devices screen. Session credentials remain on your server and are reused after normal service/server restarts. A WhatsApp logout/revocation can require a new QR scan.

WhatsApp 1–5

Slots are availability backups. Auto-routing uses eligible healthy senders. Failover is for continuity; MessageFlow does not blindly rotate after ambiguous delivery failures.

API integration is sender-agnostic: your website/app calls the same MessageFlow endpoints whether the selected sender uses Meta Cloud or Linked Device.

The dashboard checks the project, active API key, connected healthy sender, background worker and optional customer webhook. If a project uses Linked Device, R13 also requires the local Linked Device bridge to report healthy before the project is shown as ready.

Use Send Test on a connected WhatsApp slot before integrating production traffic.

POST/api/v1/messages/send

{
  "to": "919876543210",
  "message": "Your order ORD1024 has been confirmed.",
  "idempotency_key": "ORDER-ORD1024-CONFIRMED"
}

Use a unique idempotency_key for each business event to protect against accidental duplicate requests.

POST/api/v1/otp/send

POST/api/v1/otp/verify

OTP expiry, resend cooldown, verification-attempt limits and hashed storage are enforced server-side.

GET/api/v1/messages/{message_id}

Typical states: queued, processing, retrying, sent, delivered, read, failed, awaiting_sender, awaiting_connection. Downstream delivery/read states depend on the active provider.

Numbers that already have MessageFlow transactional history appear in Conversation Inbox. Automated and manual messages share one timeline. Authorized dashboard users can send a manual follow-up using Auto Sender or a selected sender slot.

Manual sends are logged with status and audit information.

Supported events include message.sent, message.delivered, message.read, message.failed and otp.verified.

Deliveries are HMAC-SHA256 signed. Verify signatures before trusting payloads. Failed deliveries retry and eventually enter the dead-letter queue, where they can be redriven.

• Per-key requests/minute limits.
• Optional exact-IP/CIDR allowlists.
• Plan project/sender/monthly-message limits when enabled.
• Login brute-force throttling and security-event logging.
• HttpOnly/SameSite dashboard sessions.
• Password changes/resets invalidate older sessions.
• Linked Device bridge is loopback-only and internally authenticated.

Rate-limited requests return HTTP 429 and Retry-After where applicable.

Linked Device QR does not appear

Confirm the linked-device service is active and the dashboard can reach the local bridge. The bridge must never be exposed through Nginx.

Linked Device says logged out

Open Connect → Scan QR again and relink from the phone.

Project is not Ready

Open Launch Readiness. Fix required blockers: active API key, sender connection, worker health, and Linked Device bridge health when applicable.

Message failed

Open Message Records for the provider error. Meta may require provider-approved templates/conversation rules; Linked Device failures can require reconnect/re-scan.