Block communication — API coverage

Block communication is a restriction you configure against a customer status label in Capillary. When a customer is assigned a label that has block communication enabled, all outbound communications to that customer are suppressed, both transactional and promotional, regardless of channel or message type.

The APIs listed on this page pass user_id to downstream communication services. The downstream service uses this identifier to look up the customer's block status and suppress communications accordingly.

📘

Related configuration

For instructions on setting up customer status and block communication labels, see Managing customer lifecycle with customer status.

How block communication works

1. In Intouch, navigate to Organisation settings > Miscellaneous > Customer status configuration.
2. Enable customer status for the org.
3. Create or select a status label (for example, Suspended).
4. Under the label, enable Block communications.
5. When any of the APIs listed below trigger a communication for a customer, the user_id is passed to the downstream communication service.
6. The downstream service checks whether block communication is active for that user_id.
7. If the block is active, all communications are suppressed. No message is delivered regardless of channel or message type.

Secondary effect: communications appear in interaction history

When these APIs trigger a communication, the event is tagged to the customer in Capillary's system and appears in the customer's interaction history. Use the Get customer interactions API to retrieve them.

APIs that enforce block communication

Request APIs

These APIs submit and approve customer requests such as identifier changes and goodwill adjustments. They trigger SMS or email notifications as part of the request workflow.

Direct communication APIs

These APIs send messages directly to customers through specific channels.

OTP APIs

These APIs generate and validate OTPs sent to customers. The user_id is passed to the downstream service so that block communication is checked before the OTP is dispatched.

📘

Note on OTP behavior

The /v2/otp/generate API does not check a customer's subscription opt-in or opt-out status before sending OTPs. OTPs bypass subscription checks by design. However, block communication configured against a customer status label does suppress OTP delivery. If a customer's label has block communication enabled, OTPs are not sent.

The /v2/otp/validate API does not send an outbound message. It is included because it passes user_id to the downstream service for status verification as part of the OTP validation flow.

Subscription API

Important notes

All communication types are blocked. When block communication is active for a customer's status label, all outbound messages are suppressed. This includes transactional messages, promotional messages, OTPs, goodwill notifications, and subscription notifications. There is no exception by message type.

Block communication vs. subscription opt-out. Block communication operates independently of a customer's subscription preferences. A customer can be opted in to all channels and still have all communications suppressed if their status label has block communication enabled.

Related

• Managing customer lifecycle with customer status
• Get customer interactions
• Add request (v1)
• Generate OTP
• Validate OTP
• Send communication message (v2)