Messaging

Twilio in a decision flow.

A Connection node calls Twilio mid-decision with the credentials your own contract issued. Whatever comes back is data the rest of the flow can read, branch on, and keep in the decision's trace.

Category: Messaging
Type: Integration
Authentication: HTTP basic auth
Test environment: Production host only

What a flow can call

4 operations, each one a step you can place on the canvas.

POST/Accounts/$data.twilio_account_sid/Messages.json
Send an SMS
Sends a text. To and From are E.164 — a leading plus, digits only.
GET/Accounts/$data.twilio_account_sid/Messages/$data.twilio_message_sid.json
Check delivery status
Fetches one message by the SM… SID that Send an SMS returned at body.sid.
GET/Accounts/$data.twilio_account_sid/Messages.json
List messages to a number
Message history, newest first. Filter with query parameters on the node — To, From, DateSent, PageSize — rather than pulling the whole account.
DELETE/Accounts/$data.twilio_account_sid/Messages/$data.twilio_message_sid.json
Redact a message body
Deletes the message record, including the text, from Twilio.

Provider documentation: https://www.twilio.com/docs/messaging/api/message-resource

Where it sits in the decision

A provider call is a node, not a side effect.

The call runs where the policy needs it — after the cheap checks that might make it unnecessary, before the rules that depend on it. Calls that do not depend on each other run together rather than in sequence.

Because it is part of the run, the response is part of the record. When someone asks why an applicant was declined months later, what Twilio returned at the time is in the trace, not re-fetched from a service whose answer has since changed.