Twilio connector — notification lifecycle
A notification is the connector's one stateful resource, tracked in the connector's local notification store. This page covers its states and the scheduling rules. How each step is implemented is in the architecture; how to call each one is in endpoints.
States
The connector records a status when a notification is created (the send call), and changes it
only on cancel. There is currently no delivery-status webhook, so a notification does not
advance from NEW to DELIVERED/ERROR on its own after the initial send
(see the connector notes).
Purge is orthogonal to status. POST …/purge marks the record purged and reports
isPurged: true; it does not change the notification's status.
Status mapping
The stored Twilio status is normalised to the Ark NotificationStatus returned by the API:
| Twilio status(es) | Ark status |
|---|---|
queued, sending, accepted | NEW |
sent, delivered | DELIVERED |
scheduled | SCHEDULED_DELIVERY |
canceled | CANCELLED |
undelivered, failed | ERROR |
| (any other) | NEW (default) |
Scheduling
A send with scheduledDateTime uses Twilio's native scheduled-message feature. The
connector validates the window before calling Twilio:
- More than 5 minutes in the future, and
- No more than 35 days in the future.
Outside that window → 422 NOT022003. Scheduled messages can be cancelled (DELETE) up until
Twilio sends them. A messaging service is configured for scheduled sends.