Skip to main content
You can send the value as the customer typed it — mask, @, uppercase. The API normalizes before comparing and deduplicating.

In brief

  • Each type has simple formatting rules.
  • Comparisons, search, and removal always use the normalized value.
  • The API does not create a contact on its own — it only links contactId if the contact already exists in the workspace.

Rules by type

Analogy: like standardizing a phone number before adding it to your address book — (11) 99999-0000 and 5511999990000 become the same entry.

channel field (optional)

Use channel to document in which context the suppression was created (e.g. whatsapp, email). The global rule per identity still applies:
  • Phone blocks all phone channels, regardless of the channel provided.
  • Email blocks email only.

Examples in practice

Phone with mask

Input:
Stored as E.164. Blocks SMS, WhatsApp, RCS, and voice for that number.

Email with uppercase

Input:
Stored as cliente@empresa.com.br.

Telegram with @

Input:
Stored as meubot (username) or numeric peer, depending on the value.

Invalid value

If the value fails type normalization, the API responds 400 with INVALID_SUPPRESSION_VALUE. See Troubleshooting.

Next steps