Key concepts

Each chat represents one customer conversation. You can send by destination and let Linq resolve the chat, or send to a known chat ID.

A chat’s customer is usually a phone number in digits, but a customer who uses a WhatsApp username can appear as a username id such as US.13491208655302741918 instead. Store it as an opaque string, never parse it as a phone number, and copy it unchanged into to when you reply. See customers who use a username.

An inbound customer message opens or extends the customer-service window. While it is open, you can send free-form content. Outside it, send an approved template. The API refuses an invalid choice; it never silently substitutes a template or coerces content.

Successful send requests return 202 after durable acceptance. Delivery, read, and failure receipts arrive later. Treat an unresolved outcome as unknown; do not blindly resend it. A failed message may also say why it failed.

SSE and webhooks tell you which chat sequence range moved. The per-chat journal contains the message content and forms the durable recovery source. Account events also have a pageable log for bounded catch-up.

Each send currently carries one member of the sealed parts union. The JSON Schemas served by GET /v1/parts/{type} are authoritative and can be used directly as tool schemas for your agent.