Subject: Unable to send a message immediately after creating a conversation (`conversation_not_found`)
Hello,
I’m experiencing a consistent issue with the API `POST /assistant/conversations/{cid}/messages` immediately after creating a conversation using `POST /assistant/conversations`.
Integration context
The service uses the Dust API to serve messages from an AI agent.
I’m using API key authentication on my workspace.
The service creates a persistent conversation via:
POST /v1/w/{wid}/assistant/conversations
with the following body:
{
"title": "gpt4_username",
"visibility": "unlisted"
}
Then, it immediately attempts (within <1s) to send a message with:
POST /v1/w/{wid}/assistant/conversations/{cid}/messages
with the following body:
{
"content": "Bonjour",
"mentions": [{ "configurationId": "xxxxxxxx" }],
"context": {
"username": "@user",
"origin": "api",
"timezone": "Europe/Paris"
}
}
Issue encountered
Every time I try to send a message right after the conversation is created, I get the following error:
{
"error": {
"type": "conversation_not_found",
"message": "Cannot access conversation: conversation_not_found"
}
}
However, the conversation creation returns `200 OK` with a valid ID (`cid`).
The problem persists even after waiting several seconds and after multiple attempts.
If I use `blocking: true` during conversation creation with an embedded message, everything works fine.
Tested hypotheses
The `conversation_id` used is the one returned by the API (verified in logs).
The `agent_id`, mentions, headers, and context are all valid.
The conversation is correctly saved and reused (in database).
I also tested `GET /events` — same `404` issue.
The problem does *not* occur with `blocking = true`, but I’d like to manage messages separately.
Question
Is there an undocumented propagation delay between conversation creation and its availability for `POST /messages`?
Is there a recommended way to wait until the conversation is accessible and active on the API side?
My goal is to post messages to a persistent Dust conversation in order to better manage message history in the service’s responses — is there another recommended way to achieve this?
Thanks in advance for your insights!