Contacts and consent

Contacts use /projects/{projectId}/contacts. A service key can access only its own project. Definitions are shared across that project’s environments, so Sandbox is not a separate CRM database. Create contacts with phone, name, tags and custom fields:

{
  "phone": "+2348031234568",
  "name": "Ada",
  "tags": ["customers"],
  "customFields": { "customerReference": "customer-001" }
}

Creation and import do not opt a recipient in. Record authentic opt-in using POST /projects/{projectId}/contacts/{id}/consent:

{
  "optedIn": true,
  "suppressed": false,
  "evidence": "Checkout WhatsApp opt-in, internal evidence record 001"
}

To suppress a recipient, set optedIn: false and suppressed: true. The API rejects suppression combined with active opt-in. Suppression is rechecked before provider delivery. Never fabricate consent or infer it from contact import. Use server-side search and tag filters plus pagination for lists. Updates require the returned version UUID and return 409 when stale. For now, the contact list response’s customFields is a JSON-encoded string; create/update requests accept an object. Parse this field explicitly if using it. Imports accept at most 1,000 entries per call. Tags are bounded to 30 per contact, 80 characters each; custom fields to 30 entries with 80-character keys and 2,000-character values. Phone uniqueness is scoped to organization/project. Contact lists provide static membership and segments provide tag/opt-in filtering. Segment counts always exclude suppressed contacts. Lists and segments do not independently authorize sending or grant consent.

Start

Build

Contacts and consent