Optionalidentity_Optionalparent_OptionalprofileOptionalname?: stringValue will be set to the WhatsApp user’s display name
Optionalusername?: stringWill be set to the WhatsApp user’s username if the user has enabled the usernames feature, will be omitted entirely for sent status messages webhooks, or if the user has not enabled the usernames feature
Will be set to the WhatsApp user’s BSUID
I think there's one super edge case scenario where user_id isn't present at all:
recipient_user_id in statusescontacts entry due to failed event's natureOther status events should work fine,
as they will always include contacts.
Internally, the library will always populate the
recipients with as much data as possible,
prioritizing the parent BSUIDs over user_id.
This (SHOULD) ensure at least one BSUID will be
available on every status event.
If you need a consistent user key across all events,
consider using (parent_user_id ?? user_id).
This is a guesstimate, can't tell for sure until BSUIDs are operational.
Such a weird restriction to not include the contacts data on failed events...
Optionalwa_User phone number, will be omitted if the user has enabled the usernames feature, will be set to the user’s phone number if you sent the message to the user’s phone number
Will be set to the user’s parent BSUID if you have enabled parent BSUIDs