---
title: "Use the reviewed communication contract"
description: "Understand Driver communication reads, writes, receipts, media, sockets, and external contact."
canonical: https://docs.ordering.co/docs/developers/driver-app/communication-contract/
---

# Use the reviewed communication contract

Driver communication spans order-conversation lists, order chat, read receipts, text/media writes, sockets, notifications, clipboard, phone/SMS/email, and map handoffs. These are separate contracts. Visibility or local state must never be used as delivery, authorization, receipt, provider, or completion proof.

The supported guidance covers viewing conversations. Message and media writes, and read-receipt completion, are unavailable for integration use here.

## Availability

| Capability                  | Current public boundary                                                                        |
| --------------------------- | ---------------------------------------------------------------------------------------------- |
| Conversation list           | Authenticated Driver order reads plus local pagination/sort/socket presentation                |
| Order chat view             | Authenticated order-participation read and audience-filtered presentation                      |
| Read receipts               | State-changing intent can begin when chat opens or closes; completion/scope claims are blocked |
| Text send                   | A client control may be visible, but sending is not supported here                             |
| Image/signature send        | Shares the blocked message-write path; upload/storage/delivery claims are excluded             |
| Document send               | Source definition exists but productive UI/payload wiring is absent                            |
| Sockets/push                | Transport intent only; no durability, security, ordering, or delivery receipt                  |
| Phone/SMS/email/map contact | External OS/provider handoff; no universal support route or provider outcome                   |

## Prerequisites

For any viewing implementation or documentation:

- Use an authenticated Driver account and an order the Driver is authorized to handle.
- Treat order/message/participant data as private and purpose-limited.
- Separate initial order read, message-list read, local filtering, socket append, read intent, and provider render.
- Do not enable send, media, receipt, contact, or external-app actions in a documentation runtime.

## Responsibility boundaries

| Owner                    | Responsibility                                                                                               |
| ------------------------ | ------------------------------------------------------------------------------------------------------------ |
| Driver App UI            | Loading, list, header, bubbles, audience presentation, composer state, local errors and handoffs             |
| Client controllers       | Authenticated reads, local state, read intent, write intent, socket listeners, and immediate preview cleanup |
| API read contract        | Authorize order participation and filter visible messages for the current role                               |
| API write contract       | Authorize before any upload/write, validate content/audience, persist atomically or return a safe receipt    |
| Read-receipt contract    | Authorize order participation and per-message visibility before mutation                                     |
| Socket/push providers    | Transport events; never define authorization or durable completion                                           |
| OS/contact/map providers | Own external app support, privacy, user confirmation, and outcome                                            |
| Product/security owner   | Resolve blocked authorization and receipt findings before public write procedures                            |

## Inputs and result

### Viewing

Inputs are an authorized order context, authenticated session, returned message rows, audience metadata, and local configuration. Safe outputs are loading, empty, populated, error, historical, or locally appended presentation states.

An image bubble, sender label, audience avatar, unread badge, or socket append is not an authorization or delivery receipt.

### Writes and media

Text and image/signature controls can construct a message intent. Media-write authorization and rollback remain under security review, and media/message/ socket/notification effects can settle separately. Public send/media procedures are therefore blocked.

Document-picker state is not transmitted by the accepted client. Do not claim document attachment support.

### Read receipts

Opening chat can trigger a state-changing read intent. Receipt-scope and visibility authorization remain under security review. Local unread zero, Back navigation, or returned rows are not read completion.

### Sockets and contact

Socket room joins/events are freshness hints, not auth or durability. External phone, SMS, email, clipboard, and map actions transfer data/control to the OS or provider. They are not support tickets, delivery receipts, or safe retries.

## Security and privacy

- Enforce authorization before upload, message persistence, or receipt writes.
- Use purpose-minimal message fields and audience; never trust client audience selection as server authorization.
- Do not log tokens, raw message/media, contact values, order IDs, coordinates, socket room names, or provider payloads in public evidence.
- Reject remote media schemes and external contact/provider actions in capture fixtures.
- Treat signature/media as sensitive content, not proof of identity, consent, pickup, delivery, or PIN validation.

## Limits and failure states

| State                    | Required interpretation                                            |
| ------------------------ | ------------------------------------------------------------------ |
| Conversation visible     | Read presentation only                                             |
| Empty chat               | No visible row passed current read/filter; not “no records”        |
| Socket event             | Local append/update intent; not durable delivery                   |
| Unread count changes     | Local/returned aggregate; not receipt completion                   |
| Send-looking bubble      | Local/response presentation; not authorized persistence            |
| Preview disappears       | Client cleared state; not upload success                           |
| Media fails to render    | Provider/source/access unresolved; do not open externally          |
| Contact/map app opens    | External handoff only                                              |
| Error after write intent | Earlier upload/write effects may still exist; do not retry blindly |

Message and media sending and read receipts are unavailable for integrations in this guide. An upload, visible bubble, or local state change does not confirm delivery or authorization.

## Troubleshooting

### Unread state differs between list and chat

Do not reconcile by opening/closing repeatedly. Reads, local zeroing, receipt mutation, socket events, and refreshed order state settle separately.

### An attachment appears selectable

Preview is local state. Image/signature send shares the blocked write contract; document transmission is unwired. Do not claim upload or delivery.

### A socket event appears to prove delivery

Sockets are transport hints. Require server authorization and durable receipts; do not use arrival order or one client view as completion.

### A phone, SMS, email, or map link is visible

Treat it as an external handoff. Do not infer provider availability, support ownership, identity, consent, or outcome.

**Related guides:** [Driver App architecture](https://docs.ordering.co/docs/developers/driver-app/architecture/) · [View order conversations](https://docs.ordering.co/docs/products/driver-app/communication/messages/) · [Use order chat](https://docs.ordering.co/docs/products/driver-app/communication/order-chat/) · [Add and view chat media](https://docs.ordering.co/docs/products/driver-app/communication/chat-attachments/)