Create a test webhook endpoint | Developer Documentation

Test a ChatArchitect webhook receiver before using it with customers

Use this guide to check a receiver for your own ChatArchitect API application. Work through local event handling, public routing and a small connection test, recording what each stage proves. The endpoint preparation checklist covers the receiver and callback contract; the ChatArchitect API quick start supplies the registration workflow and event examples.

Choose the test scope before changing a callback

• For a custom application, identify the intended account, connected business number, receiver route and person responsible for checking the result.
• For an existing CRM or help desk connector, first confirm whether it already manages the callback and how a change would affect that connection.
• Use a controlled test receiver and permitted test contact. Keep ordinary customer traffic on its agreed route while preparing the test.
• Record the existing callback setting and the supported way to restore it. Confirm the effect of registration before replacing a receiver.

Agree the callback request method, sender verification, success response, response deadline and any redelivery behavior with ChatArchitect support. The quick start documents JSON events and safe duplicate processing; it does not specify those transport details. Use the agreed contract for the test.

Check your handler locally with synthetic events

Start with the documented event shapes, replacing message references, phone values and text with fictional test data. These local fixtures exercise your application's processing; they do not register a callback or send a WhatsApp message.

Keep the local test record small: case name, intended route, validation result, processing result and any repeated action. Use your data-handling policy for diagnostic records.

Check the public route and registration

1. Deploy the intended handler to its stable HTTPS route. Check public DNS, certificate validity and the proxy path to that handler.
2. Check requests using the agreed callback method and body. A page opened successfully in a browser establishes a different kind of request; verify the handler that receives the callback.
3. Follow Step 1 of the API quick start from your server, using ChatArchitect App ID and Secret for the documented registration request. Supply your actual receiver and intended connection according to the guide.
4. Review the registration response and record its time with time zone. Keep credentials out of the diagnostic record.

A successful registration response, public route check and local fixture result each establish a separate stage. Continue with an actual test event before using the receiver for customer conversations.

Test incoming text and an outgoing result

1. Use the first-message guide with the permitted test contact and correct business number. Send a distinctive incoming text with no customer information.
2. Record when the callback reached the receiver. Check the root event kind, source, message reference and text, then confirm the item appears once in the intended conversation.
3. Reply through the supported sending workflow in the open service window. Record the synchronous result and returned message reference for that outgoing attempt.
4. Check any later message-event result against the same attempt, using the correlation rule confirmed for the connection. Compare it with the message actually seen on the test phone.
5. Record missing, unmatched or repeated events as observed. Do not infer every status, a fixed arrival order or equality between all message references from the sample guide.

Use evidence to decide the next step

Before a release, retain the receiver settings, test cases and observed results, and confirm the restoration procedure with the person responsible for the connection. If the test changed an active callback, restore the agreed receiver and verify its route and event processing.

For the direct Meta developer interface, see Meta's test endpoint example. Its application setup and verification procedure belong to that interface. The ChatArchitect test above follows ChatArchitect's documented events and agreed callback contract.