Contact prefill: sender and recipient
The sender and recipient values you supply when you create a container do more than sit in storage — they resolve to a delivery channel and prefill every screen of the recording journey that would otherwise ask for them.
Before this page
This page assumes you already know what a container holds and how delivery is triggered. Read Delivery
Prefill without a form
When your integration embeds the Recorder widget directly — without a form of its own in front of it — the widget has no other source for a name or a delivery address. Whatever you passed as sender and recipient at creation is what the journey shows and what delivery uses; there is no second chance to collect it later in that flow.
Recipient channel resolution
recipient.channel decides where the message goes, but its default is easy to get wrong.
- A recipient who only has a phone number must set channel: "sms" explicitly — leaving channel unset with only a phone does not fall back to SMS.
Phone format
recipient.phone follows E.164: a leading plus sign, a non-zero first digit, and eight to fifteen digits in total.
^\+[1-9][0-9]{7,14}$Contact resolution order
A container can carry contact values in more than one shape at once — the typed fields, a deprecated top-level field, and free-form aliases. When more than one is present, this is the order that decides which value wins.
| Order | Source |
|---|---|
| 1 | Typed sender and recipient fields |
| 2 | Top-level email field (deprecated) |
| 3 | Recognized aliases inside additionalData |
additionalData is preserved as-is
additionalData is stored exactly as you send it — nothing in it is rewritten, even when one of its recognized aliases (email, senderEmail, sender name variants, receiverEmail, receiverPhone, messageNotified) is used to resolve a contact value under the rule above.