WhatsApp Business Account - Schedules API | Developer Documentation

Separate a scheduled job from a WhatsApp sending attempt

A reminder or campaign planned for later needs a tool or application that controls when to submit the message. Confirm whether your connected CRM/help desk supports the scheduling you need. For your own service, the ChatArchitect Quick Start documents the send request; it does not document a native scheduling endpoint or a scheduling field.

Write down who controls the job

• The tool/application, business connection and person responsible for the schedule.
• The intended send time, time zone and the tool's handling of time changes. Do not compare an unlabelled local time with a UTC log.
• The recipient source, prepared message and, when needed, approved template and variable values.
• The supported way to cancel or change the job before submission.

These are planning records for your tool, not fields to add to the ChatArchitect API. Keep any job reference separate from the message reference returned after a send.

Check the message when the job actually runs

The relevant conditions can change between scheduling and execution. Check whether the business event is still valid, the recipient still expects the message and the intended connection is active. For an appointment reminder, for example, a changed or cancelled appointment should be handled by the workflow that owns that reminder.

Choose the message for the service window at execution time: use the text-reply guide and the approved-template workflow. Do not assume an ordinary reply remains allowed because the conversation was open when the job was created. Use campaign limits when coordinating a larger audience.

Test scheduling and delivery as separate stages

1. Use a permitted test contact and a small job supported by your tool.
2. Check its recorded due time and actual execution time.
3. Confirm that execution produced the intended send attempt through the selected connection.
4. Keep its response reference and check the later sending/delivery result. A job marked completed is not by itself a recipient delivery receipt.
5. Test the tool's documented cancellation/change behaviour before using it for real reminders or a campaign.

If a job or callback repeats, establish whether it represents another actual send before resubmitting. Pause the relevant workflow using its supported controls when the number or route is being changed; use change planning. Exact scheduling, cancellation, retry and duplicate behaviour depends on the connected tool or your code and needs confirmation.