Send a message
Sends a message into a chat.
Requirements
Idempotency-Keyheader: required. A UUID you mint per logical send.- The chat must be open, and you must hold the send turn (see Chat control).
Behavior
- Replaying the same
Idempotency-Keywithin 24 hours returns the original response. A refused request records no key, so the same key succeeds on retry. - An
httpsURL in message text may be promoted to its own rich-link message. Each resulting message has its ownmessage.sentormessage.failedlifecycle, correlated bygroup_id. - Rate limiting is per brand: only your own traffic can produce it, and
Retry-Afteris computed from your brand’s own refill rate. A rate-limited request is not validated: an invalid send still fails with its own error once you are back within rate. A request that fans out into several messages costs one rate credit per message.
Errors
- HTTP 400:
idempotency_key_required,body_invalid - HTTP 403:
consent_required - HTTP 409:
chat_closed,chat_owned,capability_unsupported,idempotency_key_reused,idempotency_key_processingwhile another request with the same key is still in flight - HTTP 413:
attachment_source_too_large - HTTP 422: field-level validation (
category_invalid,degrade_invalid,attachment_source_invalid,attachment_source_empty, and per-part codes), each naming the exact field at fault - HTTP 429:
rate_limited, withRetry-After - HTTP 502:
attachment_source_unavailable - HTTP 503:
send_paused,attachment_source_busy(withRetry-After), orattachment_storage_unavailable
Query Parameters
Body ParametersJSON
How long the typing indicator runs before this message, in MILLISECONDS.
THE INDICATOR IS YOURS TO ASK FOR. We show one for exactly as long as you
request and never on our own, so this field is the whole control: absent
or 0 shows no indicator at all, and a positive value shows one for
precisely that long before the message reaches the customer.
OPTIONAL by contract, and absent means the same as 0: no indicator.
We recommend asking for about 1000 ms before each message you send, and
longer when the customer is about to wait on a lookup or a handoff, so
the pause reads as thinking rather than as a stall.
Bounded at 15000 (422 code 1096, which is also what a negative
value gets). The cap is derived from the budget one send attempt gets: a
longer indicator eats the time the message send itself needs, so the send
would be cut short and retried and the customer would watch a long
indicator followed by a late message or none.
Send a message
curl https://messages.api.linqapp.com/v1/chats/$CHAT/messages \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $LINQ_AMB_API_KEY" \
-d '{
"parts": [
{
"body": "Your driver Marta is two minutes away in a blue Prius.",
"type": "text"
}
]
}'{
"id": "msg_2c7d90",
"chat_id": "chat_4f81b2",
"delivery": "queued",
"messages": [
{
"id": "msg_2c7d90",
"type": "text"
}
]
}Returns Examples
{
"id": "msg_2c7d90",
"chat_id": "chat_4f81b2",
"delivery": "queued",
"messages": [
{
"id": "msg_2c7d90",
"type": "text"
}
]
}