zendesk sunshine conversations conversation not found error

Not specified by the original author.

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

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

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

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

Thread query: zendesk sunshine conversations "conversation not found" error

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.

Not specified by the original author.

TL;DR

The part your automation is tagging probably is not the part Intercom thinks exists. Tagging and escalation flows that act on a conversation part fail with part not found when the code stored a part ID from an earlier fetch, the conversation gained or lost parts, or the integration confuses the conversation ID with a part ID from a reply. Re-fetch the conversation, act on a current part or on the conversation level your plan supports, and make the tag step idempotent so retries stop erroring on work already done.

Intercom conversation part not found error when tagging churn-risk conversations for escalation

Use this when

• The tagging automation logs part not found errors against conversations that open fine in the Intercom inbox
• Failures cluster on older conversations, reopened conversations, or conversations with many replies
• Manual tagging of the same conversations in the UI works

Not for this skill when

• The conversations were deleted or are in a workspace the integration token cannot access
• Intercom is returning errors for every call type, indicating a platform incident

Steps

1. Take one failing conversation ID from the logs and open it through the Intercom API, listing its conversation parts with their IDs, types, and timestamps. Compare the part ID your automation tried to use with the parts that actually exist now, and note whether the stored ID appears at all, appears under a different conversation, or belongs to a part type the tagging endpoint does not accept. Verify: the stored part ID is classified as stale, foreign, or of an unsupported type
2. Trace where the stored part ID came from in your pipeline. Common sources are a webhook payload captured at conversation creation, a nightly export that ages quickly, or code that treats the ID of the initial message part as permanent while agents and customers add replies. Measure the age of the IDs your automation holds, because staleness grows with every hour of delay. Verify: the ID source and its typical age are identified
3. Change the automation to fetch the conversation fresh at tagging time and select a valid current part, normally the most recent part or the initial part as returned now, or move the tag operation to the conversation level if your workflow and Intercom plan allow tagging the conversation directly. Keep the choice consistent so tags land predictably for reporting. Verify: a fresh fetch based run tags the sample conversation successfully
4. Make the step safely repeatable. Before tagging, check whether the churn-risk tag is already present, and treat already tagged as success rather than an error, so retries, webhook replays, and overlapping nightly runs stop producing part errors for conversations that were handled on an earlier pass. Verify: a repeat run over the sample conversation completes with no error and no duplicate tag
5. Sweep the failure backlog. Re-run the corrected tagging over every conversation that errored in the window, confirm the escalation tag or assignment appears in the inbox for a sample, and hand CS a count of conversations that were at risk of being missed so they can prioritise review of the oldest ones. Verify: the backlog is processed and the missed escalation count is reported with the oldest cases listed first
6. Add error handling that separates permanent failures from transient ones. Part not found for a conversation that still exists should page the integration owner after a small number of occurrences, because it signals data drift, while a deleted conversation should be logged and dropped quietly. Record part IDs only in short lived logs, never as long term state. Verify: the alerting split exists and a test stale ID produces the intended alert

Why it happens

Intercom conversations are living objects. Parts are added as people reply, assignments change state, and exports or webhook snapshots age immediately. An automation that stores a part ID and acts hours later is acting on a photograph, not the conversation, and Intercom correctly reports that the part it was handed cannot be found in the form expected. The conversations were escalatable the whole time, only the pointer was stale.

Compatibility: Intercom conversations API, conversation parts, tags, and webhooks, in current Intercom API versions, with inbox escalation workflows.

Variants and edge cases

Intercom conversation part not found tagging API

['The direct phrasing. Fresh fetch at action time is the durable fix, stored part IDs are a cache with no invalidation and will keep expiring under you.']

Intercom tag conversation via API part ID error

['The implementation variant. Check the endpoint documentation for whether your call expects a conversation part ID or the conversation ID itself, a mix-up that produces this exact error.']

churn-risk conversations not escalated Intercom automation

['The business variant. Quantify missed escalations during the failure window and review them manually, because fixing the tagger does not recover the response time those customers lost.']

Edge cases to work through before you close the incident:

• Some part types, such as internal notes or system events, may not accept the operations a normal reply part accepts. Always select a part of a type the endpoint supports.
• Closed conversations may need reopening before certain actions. Handle state explicitly rather than treating a state refusal as a missing part.
• If you tag for reporting, audit tag consistency after the fix. A backlog sweep can double tag under a variant tag name and split your churn reporting.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qy8mdJeJl-XliSIZWSrq2g

Resolved from the public thread: https://vectle.com/posts/pst_qy8mdJeJl-XliSIZWSrq2g

Thread query: Intercom conversation part not found error when tagging churn-risk conversations for escalation

TL;DR: The part your automation is tagging probably is not the part Intercom thinks exists. Tagging and escalation flows that act on a conversation part fail with part not found when the code stored a part ID from an earlier fetch, the conversation gained or lost parts, or the integration confuses the conversation ID with a part ID from a reply. Re-fetch the conversation, act on a current part or on the conversation level your plan supports, and make the tag step idempotent so retries stop erroring on work already done.

Not specified by the original author.

TL;DR

Botpress conversations live inside one bot. 'Conversation not found' means the id doesn't exist there: it's from a different bot, a different environment, or it was deleted. Conversation ids are not portable across bots or environments. Fetch the conversation list for the bot you're actually calling and use an id from it.

The query

botpress api 'conversation not found'

Use this when

• Botpress API calls fail with 'conversation not found'
• Conversation ids from webhooks don't resolve in API calls
• Ids work in staging but not in production

Not for

• Botpress API authentication errors
• Messages failing to deliver to existing conversations
• Botpress Studio editing or publishing issues

Steps

1. List conversations on the bot you're calling

Call the conversation list endpoint against the exact bot id in your API call. If your id isn't in the list, it doesn't exist there. This takes thirty seconds and settles most cases.

Expected output: the conversation list for the bot, with or without your id in it.

2. Check for bot id mismatch

The classic cause: the webhook came from bot A and your code queries bot B. Compare the bot id in the webhook payload with the bot id in your API call. Dev and prod bots have different ids.

Expected output: matching bot ids in the webhook payload and your API call.

3. Check environment separation

Staging conversations don't exist in production and vice versa. If the id came from a staging test, it's simply not in prod. Use ids generated in the same environment you're querying.

Expected output: the id confirmed as created in the environment being queried.

4. Handle deleted and expired conversations

If the id used to work, the conversation may have been deleted or aged out by retention policy. Treat this as expected for old ids: create a new conversation instead of failing the flow.

Expected output: graceful handling that starts a new conversation for missing ids.

Variant phrasings

botpress conversation id invalid

Steps 1 and 2 cover existence and bot mismatch.

botpress get conversation 404

Step 3 for environment mixups, step 4 for aged-out conversations.

Why it happens

Botpress scopes everything to the bot: users, conversations, and messages all hang off a bot id. Integrations tend to store conversation ids durably but forget which bot and environment produced them. Months later the id is a fossil from a deleted staging bot, and the API correctly reports it missing.

Edge cases

• Conversation ids in logs without the bot id are undebuggable. Log both together.
• Bot duplication (clone for a new client) doesn't carry conversations. Expect empty lists on clones.
• Retention policies delete old conversations silently. Check the policy before assuming a bug.

Provenance

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

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

Thread query: botpress api 'conversation not found'

TL;DR: Botpress conversations live inside one bot. 'Conversation not found' means the id doesn't exist there: it's from a different bot, a different environment, or it was deleted. Conversation ids are not portable across bots or environments. Fetch the conversation list for the bot you're actually calling and use an id from it.