Request contact sharing

Send a message with the native share-contact button. The recipient chooses whether to share their phone number with the business.

Routes and authentication

Use the company API token created in Settings → Integrations → API Tokens. Restricted tokens need the waba scope, including on the unified route. Legacy tokens without scopes remain allowed. CHANNEL_UUID must belong to the token company.

POSTAuthentication
/api/v1/channels/CHANNEL_UUID/request-contactWABA or ZuckZapGo; company API token
/api/v1/waba/CHANNEL_UUID/request-contactWABA only; company API token
/api/messages/request-contactChannel associated with the connection token; Authorization: Bearer CHANNEL_TOKEN

WABA example: request by phone number

Replace CHANNEL_UUID, YOUR_API_TOKEN and the phone number with your integration values. Include the country code and use digits only. The message text must contain 1 to 1024 characters.

curl --request POST 'https://backend.sendeasy.app/api/v1/channels/CHANNEL_UUID/request-contact' \
  --header 'Authorization: Bearer YOUR_API_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{"to":"5511999999999","body":"Share your contact so we can continue assisting you."}'

WABA: contact without a phone number

If you receive only a BSUID, pass that opaque identifier in to unchanged. A username is a display attribute and does not replace the recipient identifier. SendEasy sends a native request_contact_info message to Meta. Availability and sending rules depend on the account and provider.

{
  "to": "BR.Example123",
  "body": "Share your contact so we can continue assisting you."
}

ZuckZapGo: phone number or LID

For a WhatsApp channel using ZuckZapGo/WuzAPI, use the same unified route and include id, required with 1 to 128 alphanumeric characters. The recipient can be a phone number, phone JID or full LID. BSUIDs, usernames, groups and device-suffixed JIDs are not accepted by this integration.

{
  "to": "123456789012345@lid",
  "body": "Share your contact so we can continue assisting you.",
  "id": "ContactRequest202610060001"
}

Response and delivery confirmation

HTTP 200 returns the provider response. For WABA, messages[0].id identifies the accepted message. Acceptance does not confirm delivery: follow Meta statuses events or query the status route below. This endpoint does not itself create an outgoing message or a ticket in the WABA inbox.

{
  "messaging_product": "whatsapp",
  "contacts": [{ "input": "5511999999999", "wa_id": "5511999999999" }],
  "messages": [{ "id": "wamid.EXAMPLE" }]
}
curl 'https://backend.sendeasy.app/api/v1/waba/CHANNEL_UUID/messages/MESSAGE_ID/status' \
  --header 'Authorization: Bearer YOUR_API_TOKEN'

When the recipient shares their contact

The shared contact follows the normal inbound message flow, and the original payload is preserved when forwarding webhooks. For the official API, the card has origin: "contact_request"; the phone is in contacts[].phones[].wa_id. For ZuckZapGo, the Message event has contactMessage.isSelfContact: true; the vCard contains the shared identity. Correlation uses the conversation within the company and channel. An ordinary third-party contact card must not replace the sender identity.

Errors and retries

The stable ID and idempotency described here apply to ZuckZapGo. Reuse the same id and payload when a retry is allowed. SendEasy does not automatically retry. Including id on WABA does not add sending idempotency.

ErrorMeaning
CONTACT_REQUEST_BODY_INVALIDEmpty text or more than 1024 characters.
CONTACT_REQUEST_RECIPIENT_INVALIDRecipient is invalid for the provider.
CONTACT_REQUEST_ID_REQUIREDZuckZapGo requires an alphanumeric ID with 1 to 128 characters.
CHANNEL_NOT_FOUNDChannel is missing or outside the token company.
CONTACT_REQUEST_DISPATCH_UNKNOWNOutcome is unknown after a timeout/transport failure. Do not automatically resend.
contact_request_dispatch_unknownThe provider cannot determine whether it dispatched. Do not resend or generate a new ID.
contact_request_id_conflictThe ID was reused with different data.

Other errors retain the provider HTTP status and details in provider. Confirm that the account supports this message type. A failure documented by the provider as occurring before dispatch may allow a retry with the same ID and payload.

See also Public API and WABA API.

Essa informação foi útil?