## TL;DR
"Conversation not found" in Sunshine almost always means the id you are using is not a conversation id in this app: it is a switchboard id, a user id, or a conversation from a different app or environment. Confirm the id came from a conversation object, that the app id matches, and that you are hitting the right environment. Sunshine ids are only meaningful inside their app and environment.

## The query

```text
zendesk sunshine conversations "conversation not found" error
```

## Use this when

- Conversation API calls return 404 not found
- Ids copied from webhook payloads fail on read
- The error appears after switching environments
- You are building on Sunshine Conversations

## Not for

- Messages failing to send on existing conversations
- Webhook signature verification
- Sunshine admin or channel configuration
- Participant management issues

## Steps

### 1. Confirm the id is actually a conversation id

Sunshine payloads carry several ids: app, user, conversation, message, switchboard. Verify the value you are passing came from a conversation object or a conversation-scoped webhook event, not from a neighboring field.

Expected output: id traced to a conversation object.

### 2. Check the app id

Conversations belong to an app. A conversation id from app A 404s when queried under app B. Confirm the app id in your request matches the app that owns the conversation.

Expected output: app id matches the conversation's app.

### 3. Check the environment

Sandbox and production are separate worlds with separate conversations. An id captured in sandbox does not exist in production. Confirm which environment issued the id and query that one.

Expected output: environment matches the id's origin.

### 4. Verify the conversation still exists

Conversations can be deleted or the owning integration removed. List recent conversations for the user to confirm the conversation is still present before assuming an id problem.

Expected output: conversation confirmed present or confirmed gone.

### 5. Re-fetch the id from the source of truth

Instead of passing stored ids around, re-resolve: look up the user, list their conversations, pick the current one. Fresh resolution eliminates stale-id bugs permanently.

Expected output: a freshly resolved conversation id that reads successfully.

## Template: the checklist

```text
Sunshine "conversation not found":
[ ] Value confirmed to be a conversation id (not switchboard/user/message)
[ ] App id matches the conversation's app
[ ] Environment matches where the id was issued
[ ] Conversation verified still present via user lookup
[ ] Id re-resolved fresh from the user record
```

## Variant phrasings

### sunshine conversations 404 on conversation id

Steps 1 and 2. Id type and app scoping.

### conversation id from webhook not found

Steps 1 and 3. Webhook ids plus environment mismatch.

### sunshine api wrong app id

Step 2. App scoping is the whole answer.

## Why it happens

Sunshine's id space is namespaced by app and environment, but the ids themselves are opaque strings that all look alike. Nothing in a bare id tells you which app or environment it belongs to, so ids get mixed across apps, environments, and id types constantly. The 404 is the API telling you the id is valid-looking but not hers.

## Edge cases

- Switchboard handoffs create new conversation references. The pre-handoff id may no longer be the live one.
- Test users and test conversations get cleaned up. Ids from old tests 404 by design.
- Multi-app setups: the same end user has separate conversations per app. Always scope by app.
- Webhook redelivery with stale payloads: verify the id fresh on redelivery instead of trusting the stored one.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jseN60gbmCaY6uD6IREYIA