Skip to main content
The Booking Engine implements Twilio SMS/MMS and WhatsApp intake contracts. This page does not claim a current Twilio phone-number, sender, webhook, credential, or fresh message-delivery state.

Source-implemented intake

Verified in Engine dev source at e2166b86ac6794a1423c7b2ce1b293a3dba505c4 on 2026-09-10:
  • The Engine distinguishes Twilio SMS/MMS and WhatsApp intake.
  • Provider-originated requests are authenticated and validated before channel identity is accepted.
  • Text and media evidence are normalized into Engine-owned maintenance truth.
  • The source records typed receipt, duplicate-handling, routing, and durable- media outcomes.
Exact callback URLs, authentication material, provider identifiers, and field mappings are private implementation details. An implemented intake contract is not proof that the Twilio console currently targets a deployed environment.

Outbound: the payment request by text

Twilio is also an outbound door. When the owner taps Send text on Lucia’s payment-request draft in the payment record (Lucia asks Quinn for a new card, LUCI-210), the Engine sends the draft as an SMS through the existing Twilio provider door (sendPaymentRequestSms, sender TWILIO_SMS_FROM by name). The text carries the full checkout URL in the message body; the email face of the same request rides Resend (LUCI-232). The send is recorded on the booking as an outbound message with its channel, and the payment record reads “Sent · waiting” from that ledger. The button appears only when the booking record has a phone. Sending is a side effect that happens on the owner’s tap and never before it.

Source configuration contract

The Engine source defines server-side provider authentication and media-access requirements. Their presence in source does not prove that any Development or Staging environment currently satisfies them. Credential values, phone numbers, messaging senders, account identifiers, and provider webhook settings must stay out of public documentation.

Media boundary

Source behavior supports:
  • SMS text normalization;
  • MMS and WhatsApp media normalization; and
  • an explicit durable-media or non-renderable fallback outcome.
Fresh proof requires the same-message chain: Twilio receipt, authenticated acceptance, Engine outcome, durable-media outcome, and rendered operator result. None of that live chain was rerun on 2026-09-10.

Future-channel boundary

The verified maintenance route is an SMS/MMS/WhatsApp contract. Voice is a future channel, not part of this page’s public title or current capability claim. Any future call, voicemail, transcription, or after-hours voice path requires its own route, authorization, provider configuration, and evidence.

Dated evidence — 2026-04-27

The 2026-04-27 release record said Twilio and WhatsApp intake, including the durable-media outcome, was working. Preserve that as historical evidence only; it is not fresh provider or delivery proof.

See also