Communicate

Beta

Augno has a messaging layer built into the platform, so the conversation about an order lives next to the order itself. Your team messages each other, customers reach you through the portal or by email, and agents take part in the same threads — all on one set of resources under /v1/messaging.

Preview

Every messaging endpoint is in public preview. The paths and payloads described in this section are real and current, but they may change while the surface stabilizes, so pin the API version you build against and read the release phases page before you depend on them in production.

Conversations are the container

Everything in messaging hangs off a conversation. A conversation has a type that says what kind of container it is:

Direct messages are de-duplicated: asking for a direct message that already exists returns the existing thread rather than a second one. They also have no stored title — clients derive a name from the participants.

Audience is orthogonal to type

Separately from type, every conversation carries an audience:

• internal — a team-only thread. The customer is never a participant and never sees it, even when the thread is entirely about them.
• customer — an external case the customer takes part in and can read, opened from the customer portal or bridged from an email inbox.

audience is what separates "the team discussing an order" from "the customer asking about an order." A customer conversation additionally carries a workflow_status triage lane (new, open, waiting_internal, waiting_external, needs_approval, resolved) that drives the support inbox; on an internal conversation that field is null.

Inside a customer case, safety is enforced one message at a time. Each message has a visibility of internal (a team-only note), external (sent to or received from the customer), or system (an event both sides see), and a customer reading their own case is never served internal messages.

Conversations can be anchored to a record

A conversation may be anchored to a business record at creation time with topic_resource_type and topic_resource_id — a sales order, an invoice, a shipment, a customer. That anchor is what makes a thread show up as the discussion on that record: listing conversations by topic_resource_type + topic_resource_id returns it.

Beyond the single anchor, a conversation can link any number of additional records. Listing by business record matches the anchor and the links alike, so one thread can surface on several records at once.

Who is in a conversation

Participants are membership records, not raw user references. Each one has a type (user, agent, system, or customer), a role (owner, admin, member, viewer), a membership state (active, left, removed, hidden), a per-conversation notification preference, and a read cursor. Membership records are kept rather than deleted, so someone who left and came back keeps their history and their earlier messages stay attributed to them.

Two kinds of state

The status on a conversation reflects the caller's own view of it and has three values:

• active — normal and visible.
• archived — archived for the whole account, so every participant reads it back as archived. On a customer-facing case this also moves it out of the working support inbox; an internal thread stays in its participants' lists, just flagged archived.
• hidden — the caller dismissed it from their own list while everyone else still sees it. Hidden takes precedence over an account-level archive.

Read/hide/mute/leave are per caller; archive is per account. Keeping the two apart is the thing most integrations get wrong first.

Next: Messages