WhatsApp Cloud API Get Started | Developer Documentation

Prepare your first ChatArchitect WhatsApp API integration

Use this guide when a developer will add WhatsApp messaging to your own application through ChatArchitect. It covers the connection decisions, receiver preparation and first controlled checks. Use the ChatArchitect API quick start for the current request examples and field definitions.

For an existing CRM or help desk, begin with the integration-route guide and the setup for your tool. Confirm who manages its callback before adding or changing one.

Prepare the connection and a small test

• A business number connected through the supported ChatArchitect number setup.
• The credentials issued for that connection and a developer responsible for storing and using them on the server.
• A public HTTPS receiver, a verified mapping to the intended connection and an agreed callback contract.
• A permitted test contact, a distinctive test message and the application conversation where the reply should appear.
• A record of existing settings and the supported way to restore them if the test changes an active connection.

Use the credentials and interface in the current guide

The quick start uses https://api.chatarchitect.com as the API base URL and Basic Auth for its API requests:

The credentials guide covers App key/Secret in supported setup forms. If the field label or issued value is unclear, confirm it for your connection before sending requests. Review the phone-format rules in the API quick start: its request examples use international digits without a plus sign, spaces or brackets.

Prepare and register the receiver

1. Work through the receiver checklist and agree sender verification, callback request method, acknowledgement response/timing and redelivery behavior for the connection.
2. Check the public HTTPS route and your event handler. A browser page load and a local synthetic event each establish one part of the preparation.
3. Confirm the effect on any existing callback, then follow Step 1 of the quick start to register the intended receiver from your server.
4. Keep a redacted registration result and its time with time zone. Continue with an actual permitted connection test to check event receipt.

The quick start documents JSON events and safe duplicate processing but leaves several transport details unspecified. API Basic Auth describes the registration request; agree the incoming callback's verification requirements separately. The staged receiver test explains how to distinguish local handling, public routing and observed message events.

Use the three documented API operations

Copy request structures from the current quick start and supply values for your connection and permitted test recipient. Check the operation and intended effect before sending it. The table above is a preparation checklist; the guide supplies the actual request and response examples.

For the documented structures, use the message-send reference, approved-template list reference and callback payload reference. They cover request bodies, template send syntax and the two event shapes illustrated in the quick start. Confirm additional operations and incoming transport details for the connection before implementing them.

Check incoming text, a reply and a template

1. Have the test contact write to the business number. Use the incoming-text guide to validate the root message event, nested text kind, source, reference and text, and confirm the intended application conversation.
2. Send one ordinary reply through /whatsappmessage inside the active service window. Use the first-message guide for the message rules.
3. Record the synchronous result. A submitted response represents acceptance into the queue; inspect the later message-event using the delivery-status guide.
4. Fetch the approved templates with /getHSM. Select one suitable for the permitted test, review its text/variables and follow the quick start's template syntax. The template guide covers preparation in the ChatArchitect cabinet.
5. Observe the small template test separately from the earlier text reply. Compare request, available callback result and what the test phone actually received.

Use the correlation rule confirmed for your connection. Preserve unmatched or missing results for diagnosis; the sample does not establish universal equality between references, a fixed event order or receipt of every status.

Record what each result establishes

Before customer use, retain the small test results and unresolved issues, confirm who handles incoming replies and apply the message-data guide to your application's records. For support, share the operation, connection, time, available reference and redacted error without credentials or customer content.

Meta's direct Cloud API guide describes its developer-app and access-token workflow. The ChatArchitect preparation above uses ChatArchitect's issued connection credentials and current API reference.