Contacts messages webhook reference | Developer Documentation

Handle incoming WhatsApp contact cards with ChatArchitect

A customer may share a contact card while arranging a referral, delivery or handover. Check how the specific ChatArchitect connection receives that card before using its details to create or update a CRM record.

The ChatArchitect API quick start documents incoming text events. It does not specify incoming contact-card payloads or automatic CRM contact creation. Ask support to confirm the receiving format and behavior for your API application or ready-made integration.

Separate the sender from the shared person

Meta's contact-message reference allows one or more shared cards, and some properties can be absent because of the sender's sharing choice or device. In that reference, the sender's profile and the cards inside the message are separate data. These distinctions help interpret a received card; they do not define the ChatArchitect callback format.

• Keep the conversation attached to the actual sender and connected business number.
• Check each shared card separately. The person named on a card may be someone other than the sender.
• Inspect all available phone entries before choosing a number. An absent phone number or email does not establish that receipt failed.
• Do not overwrite the sender's CRM name or number with a shared person's details. Apply your own matching and review rules before updating another contact.

Verify the receiving workflow

1. Identify the connected business number and the receiving CRM, help desk or custom application. Confirm incoming contact-card support for that exact route.
2. For a custom application, obtain a redacted ChatArchitect event example, the card collection and field mapping, and the supported rule for message references. Use the receiver checklist before changing a live callback.
3. With a permitted test account and non-sensitive test details, send an ordinary text as a baseline, then share one card. Follow the incoming-text checklist to confirm the baseline route.
4. Compare what was shared on the phone with the received chat item or supported callback. Record the time with time zone and available message reference.
5. If multiple cards are supported, check that each is visible and correctly attributed. Inspect which fields were supplied before diagnosing a missing phone or email.
6. Review any create-contact or update-contact action separately. Confirm the destination record and duplicate-handling rules before enabling automatic changes.

A text reaching the conversation confirms the baseline path; contact-card support still needs its own check. For duplicate events, use the webhook overview and avoid creating a second CRM record from a repeated receipt.

When the card is missing or misleading

If the route cannot display the card, ask the customer to send the relevant name and number as text. A shared card alone does not establish that the named person agreed to receive campaigns; check your permission workflow before messaging them.

For support, provide the connection, integration version, test time, available reference and the difference between the shared and received card. Redact third-party details and follow the data-handling guide. For the opposite direction, use the sending contact-card guide.

See Meta's incoming-contact reference for platform details. Implement the format confirmed for ChatArchitect.