<!-- https://missblue.dev/docs/conversations -->

Product guide

# Resolving and internal notes

Two things you do to a conversation rather than inside it: mark it finished with, and talk about it without the customer hearing.

Resolved is a team state

Not per person. Two people pressing Resolve at the same moment resolves it once, enforced by the database rather than remembered by the code.

A reply reopens it

Automatically, the moment it arrives. A conversation still filed under Resolved after the customer answered is one nobody is looking at.

A note can never be sent

Whispers live in their own table. No send path reads it, so there is no route by which an internal note reaches the customer it is about.

Resolving is a moment

Append-only, so “how many did we resolve last week” survives somebody replying — and an automation can trigger on the moment itself.

## One conversation, more than one id

Messages keeps a separate chat per transport, so a conversation that starts as SMS and continues over RCS has more than one `chat_id` behind it. Miss Blue shows it as one conversation: `/v1/threads` returns a single thread, and an id you stored before the transport changed keeps working.

Any id the conversation has ever had is accepted when listing its messages, marking it read, pinning it, reporting who is typing, and resolving, reopening or noting it. Group chats are never merged, and location requests address the exact chat you name.

Webhooks report the same id the thread list uses. The person you are texting sees one conversation throughout — phones thread on the phone number, not on how a message travelled.

## Resolve one

Resolving something already resolved is not an error — you get the same answer the first caller did.

```bash
curl -X POST https://api.missblue.dev/v1/projects/$PROJECT/conversations/resolve \
  -H "Authorization: Bearer $MISS_BLUE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"chat_id":"iMessage;-;+13055550142","handle":"+13055550142"}'

{"resolved": true, "resolved_at": "2026-09-19T15:02:11Z", "resolved_by_user_id": "…"}
```

## Reopen one

```bash
curl -X POST https://api.missblue.dev/v1/projects/$PROJECT/conversations/reopen \
  -H "Authorization: Bearer $MISS_BLUE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"chat_id":"iMessage;-;+13055550142","handle":"+13055550142"}'
```

## Leave a note

`mentions` holds the user ids to tell. Anybody who cannot already see the project is dropped: a mention is a link to a customer conversation, and sending that outside the team would hand somebody the conversation.

```bash
curl -X POST https://api.missblue.dev/v1/projects/$PROJECT/conversations/whispers \
  -H "Authorization: Bearer $MISS_BLUE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "chat_id":"iMessage;-;+13055550142",
        "handle":"+13055550142",
        "body":"Card on file bounced — take payment on the day.",
        "mentions":["<user id>"]
      }'
```

## Read the notes

Scoped to the project in the path. A `chat_id` comes from the platform and proves nothing on its own, so one project cannot read another’s notes by guessing one.

```bash
curl https://api.missblue.dev/v1/projects/$PROJECT/conversations/$CHAT_ID/whispers \
  -H "Authorization: Bearer $MISS_BLUE_API_KEY"
```

[Next Automations Send a survey or a follow-up the moment a conversation is finished with.](https://missblue.dev/docs/automations)