WhatsApp Cloud API - Message API | Developer Documentation

Send a WhatsApp message with the ChatArchitect API

Use this reference to prepare an ordinary text reply or an approved template through your connected ChatArchitect account. The ChatArchitect API quick start supplies the documented interface. Use the first-integration checklist to prepare the connection and receiver before a permitted test.

Authenticate the request from your server

Send JSON to POST https://api.chatarchitect.com/whatsappmessage with Basic Auth. The quick start uses APP_ID as username and APP_SECRET as password. Use the issued App key/Secret values for your connection; see the credentials guide if the form labels differ.

An SDK's HTTP Basic Auth option can construct the header from those values. Keep real credentials on your server and out of browser code, screenshots, request URLs and public logs.

Prepare an ordinary text request

The JSON below follows the documented text structure with illustrative content. Replace the recipient placeholder only in a permitted test. The destination uses international digits without a plus sign, spaces or brackets.

{
  "channel": "whatsapp",
  "destination": "<recipient_phone>",
  "payload": {
    "type": "text",
    "message": "Thank you. We will check your request."
  }
}

Use an ordinary reply inside the active 24-hour service window after the customer's message. A business-initiated message outside that window needs an appropriate approved template. Check the text-reply rules and the recipient's permission for the intended message. Do not substitute a username or business-scoped user ID into the documented phone destination.

Use the returned template send string

Fetch the approved list using the template-list reference. Select the intended entry and inspect its data. Keep the required first {{template_id}} block and the separator before its text. Fill numbered variables in their original order; do not remove the template ID or replace it with a name.

The quick start illustrates a template prefix followed by a newline and text. In JSON, that newline is encoded as \n. A variable can contain spaces and several words, but its value must not contain a line break. Follow the returned string and quick-start example rather than inventing another request schema.

Review the recipient and completed message before a small permitted send. The component guide helps review text and buttons. A category in the list does not confirm every special template format as a supported feature.

Separate acceptance from delivery

An illustrative synchronous response is:

{
  "status": "submitted",
  "messageId": "<example_request_reference>"
}

For this send operation, submitted means the request was accepted into the queue. It does not prove delivery or reading. Keep the returned messageId with the operation, connection, recipient, time and internal attempt record. The later root message-event reports the result; inspect it with the delivery-status guide and callback payload reference.

Apply the correlation rule confirmed for your connection. The examples do not establish universal equality between messageId and callback payload.id, a fixed status order or receipt of every status. Preserve an unmatched result for diagnosis.

Check a failure before another attempt

• If the API request fails, record its HTTP result and redacted error. Check the operation, issued credentials, phone format and connection.
• If a submitted attempt later fails, preserve its available reference, code and reason. Use the outgoing-error guide to investigate that attempt.
• If no result reaches your application, inspect registration and handling with the staged callback test.
• Before retrying, establish the previous outcome and the duplicate-prevention rule. The quick start does not specify automatic retries or an idempotency-key contract.

Apply your application's data-handling rules to diagnostic records; share references and redacted errors without credentials or customer text.

Meta's Message API reference describes its direct provider interface. Use ChatArchitect's issued credentials and current request structures for the workflow above. Ask support for a confirmed request before adding a different message type.