Authorization
Bearer tokens are scoped to tenant, environment, principal, and allowed actions.
A static review surface for the planned Chat contract: scoped sessions, conversations, membership, messages, read state, safety workflows, realtime events, and retry semantics.
Contract shape
The proposed surface uses resource-oriented HTTP for application clients, a matching Connect/gRPC domain contract for backend clients, and WebSocket event delivery for responsive product interfaces. Durable history remains the recovery source of truth.
Scoped session token
Tenant + membership + policy
Idempotency key
Recoverable WebSocket
Bearer tokens are scoped to tenant, environment, principal, and allowed actions.
The tenant is derived from validated credentials; callers do not switch it with a free-form header.
Create and mutation retries use an Idempotency-Key and domain-specific client identifier where applicable.
Lists use opaque cursors. Message history also exposes conversation sequence for recovery.
PATCH requests name intended fields so omitted values are not confused with deletion.
Responses and errors include a request identifier suitable for operational correlation.
Proposed private-pilot routes
Exchange trusted application context for narrowly scoped Chat access.
/v1/chat/sessionsRequests tenant, user, environment, and action scopes from a trusted application boundary.
/v1/chat/realtime-ticketsIssues a short-lived, single-purpose ticket for a permitted WebSocket connection.
Proposed private-pilot routes
Create and retrieve tenant-scoped direct, group, and channel conversations.
/v1/conversationsCreates a conversation with kind, initial members, policy, and optional product metadata.
/v1/conversationsReturns conversations visible to the current principal using cursor pagination and filters.
/v1/conversations/{conversation_id}Returns the permitted conversation projection, membership, and current sequence state.
/v1/conversations/{conversation_id}Updates allowed metadata or settings after membership and Authz checks.
Proposed private-pilot routes
Manage membership, roles, mute state, and participant lifecycle.
/v1/conversations/{conversation_id}/membersAdds a user when the caller can manage membership in the conversation.
/v1/conversations/{conversation_id}/members/{user_id}Changes allowed role, mute, or notification state with explicit field selection.
/v1/conversations/{conversation_id}/members/{user_id}Ends membership while retaining the durable conversation history required by policy.
Proposed private-pilot routes
Publish, page, edit, soft-delete, reply to, and react to durable messages.
/v1/conversations/{conversation_id}/messagesAccepts retry-safe message content, reply context, and validated attachment references.
/v1/conversations/{conversation_id}/messagesReturns durable history before or after a sequence cursor for paging and recovery.
/v1/messages/{message_id}Applies an allowed content edit while preserving revision metadata.
/v1/messages/{message_id}Removes visible content according to role and policy without erasing required operational history.
/v1/messages/{message_id}:reactAdds or removes the principal’s reaction with idempotent semantics.
Proposed private-pilot routes
Synchronize product state and locate content inside the caller’s permitted scope.
/v1/conversations/{conversation_id}/read-stateMoves the principal’s last-read sequence forward without allowing a stale client to move it backward.
/v1/messages:searchSearches only conversations and fields visible to the current tenant-scoped principal.
Proposed private-pilot routes
Report content and apply policy-controlled moderation actions with an audit boundary.
/v1/messages/{message_id}:reportRecords a structured user report for product-defined moderation handling.
/v1/conversations/{conversation_id}:moderatePerforms an allowed hide, remove, mute, block, or membership action with policy and audit context.
Message example
The target publish contract makes client retries explicit. A successful response represents a committed message and outbox entry; realtime and downstream processing follow through asynchronous delivery.
{
"client_message_id": "client_message_9c12",
"text": "Release checklist is ready",
"reply_to_message_id": null,
"attachment_ids": ["media_01J..."]
}{
"message": {
"id": "msg_01J...",
"conversation_id": "conv_product",
"sequence": 1842,
"sender_id": "user_42",
"text": "Release checklist is ready",
"created_at": "2026-07-16T10:24:00Z"
}
}The proposed WebSocket stream delivers tenant-scoped events after a client exchanges its chat session for a realtime ticket. Clients deduplicate by event identity, apply per-conversation sequence, and recover missing ranges through the history endpoint.
{
"event_id": "evt_01J...",
"type": "chat.message.created.v1",
"tenant_id": "tenant_acme",
"conversation_id": "conv_product",
"sequence": 1842,
"occurred_at": "2026-07-16T10:24:00Z",
"payload": {
"message_id": "msg_01J...",
"sender_id": "user_42"
}
}conversation, membership, message, reaction, read state, and moderation changes
typing, presence, connection hints, and transient delivery signals
monotonic sequence inside a conversation; no global event order
at-least-once with event-id deduplication and durable-history recovery
Errors use machine-readable codes and an explicit retry hint. Clients should retry only retryable failures, preserve the idempotency key, and use bounded backoff. Authorization failures are not converted into empty successful responses.
{
"error": {
"code": "conversation_access_denied",
"message": "The principal cannot perform this action.",
"request_id": "req_01J...",
"retryable": false,
"details": []
}
}| Category | Client behavior |
|---|---|
| Validation | Correct the request; do not retry unchanged. |
| Authentication | Refresh the valid application or chat session. |
| Authorization | Stop and surface the denied action without probing adjacent resources. |
| Conflict | Refresh durable state and reconcile the intended update. |
| Rate or capacity | Honor server guidance and retry with bounded backoff when marked retryable. |
Governed agent boundary
There is no proposed unrestricted Chat MCP endpoint. The private-pilot tool catalog is mediated by Agent Gateway so tenant and environment scope, tool allowlists, read or write access, budgets, policy, expiry, revocation, approvals, and Audit Log events remain enforceable.
chat.list_conversationsReadLists conversations inside the agent’s explicit scope.
chat.get_messagesReadRetrieves permitted durable history with a cursor.
chat.search_messagesReadSearches only authorized tenant and conversation content.
chat.send_messageApproval requiredPublishes the pilot write only after an approval decision.
Next step
Private-pilot discussions start with your participant model, moderation boundary, attachment needs, client platforms, workload shape, recovery expectations, and customer-cloud constraints.