Identity Change | Developer Documentation

Review a WhatsApp identity-change signal in ChatArchitect

If the connected tool or support reports a possible change to the person controlling a customer's WhatsApp account, review the customer association before sending personal account information. A familiar display name or earlier conversation is insufficient to resolve that uncertainty.

This guide concerns a cryptographic identity-change signal. A phone-number or user-ID change and a change to the business number's two-step-verification PIN are separate cases.

The ChatArchitect API quick start does not specify identity-change controls, notification fields, automatic send blocking or an acknowledgement endpoint. Confirm whether the feature is used for your connection and who handles it before interpreting a provider notice as an installed ChatArchitect workflow.

Understand what the signal establishes

Meta's identity-change guidance describes an optional provider feature for detecting a potential change in a customer's cryptographic identity. When that feature is enabled, outgoing messages to the affected account can be blocked until the business acknowledges the notice. Meta recommends re-authentication outside WhatsApp before restoring trust.

• A potential change is a reason to review identity; it does not by itself prove that the account was taken over.
• A technical acknowledgement does not establish that the person is trusted. Verification and the decision to continue sharing customer information are separate business steps.
• Do not assume every ChatArchitect connection has this optional feature enabled or exposes the same controls.
• Keep a cryptographic-identity notice distinct from a changed username, phone number or BSUID. A matching display name does not resolve any of these cases.

Review the customer association through your normal process

1. Identify the business connection, receiving integration and affected conversation. Record the time, exact notice and any references exposed by the supported route.
2. Ask support or the responsible integration administrator to confirm the notice's origin, enabled feature and actual sending restriction, if any. Use the webhook overview for event receipt and mapping.
3. Arrange review of affected future sends that contain personal information, using the controls available to your team. Check queued or accepted attempts separately; a local pause does not establish cancellation by the service.
4. Use your organization's established customer-verification route outside the uncertain WhatsApp conversation. Confirm the person and intended customer record before restoring that channel's trusted association.
5. Record the verification outcome and the authorized decision about future sharing. Review linked CRM records and open tasks so an old conversation cannot silently establish trust for a different person.
6. If a technical acknowledgement is required, have the responsible operator use the supported procedure after the review. Obtain ChatArchitect's instructions; do not invent a Cloud API request or send credentials to the customer.
7. After the supported restriction is resolved, inspect the permitted communication route and any affected sending results before resuming the reviewed workflow.

An authentication code sent into the uncertain conversation is not a substitute for the established independent verification route. This checklist does not prescribe a new customer-login product, an OTP template or a Meta API integration.

When the notice or restriction is unclear

For a custom application, request a redacted supported example and confirm notification identity, account scope, repeated-event behavior and the distinction between acknowledgement and trust. Review your local handling with that sample; a real customer does not need to change their account or device to manufacture a test signal.

For support, provide the connection, integration version, time with time zone, exact notice/error, available references and the review stage that remains unresolved. Keep the evidence within your organization's approved data-handling process. See Meta's identity-change guidance for the provider feature.