email or linkedin_url (at least one is required on create). Exclusions can be permanent or time-limited via the optional until field, and carry a structured reason code to help you report on and audit your blocklist.
Read endpoints require the
contact_exclusions:read scope. Create, update, and delete endpoints require contact_exclusions:write. Account exclusions have their own account_exclusions:* scopes.Create an exclusion
POST /v1/contact-exclusions requires reason and at least one of email or linkedin_url. Optional fields include message (a free-form operator note) and until (an RFC 3339 timestamp after which the exclusion expires — omit for a permanent block).
List and manage exclusions
GET /v1/contact-exclusions returns every contact exclusion in your workspace with the standard pagination envelope. Filter by email, reason, or creation timestamps.
GET /v1/contact-exclusions/{exclusion_id} fetches a single rule. PATCH updates mutable fields (reason, message, until). DELETE permanently removes the exclusion.
To block an entire company domain instead of one person, use account exclusions.
Exclusion reasons
Every contact exclusion carries areason field. Valid values are:
Webhook: contact_exclusion.created
When a contact exclusion is created, Topo can push a contact_exclusion.created event to your webhook subscriptions. This is a resource event — it is not tied to a sequence run, so the payload has no sequence_id or sequence_template_id.
Deliveries are sent only to subscriptions whose sequence_template_ids is null (all templates). The payload includes:
Subscribe to
contact_exclusion.created when you need to mirror Topo’s blocklist into an external system the moment someone opts out.