[GH-ISSUE #1175] Backend-Controlled API Flow - not working for me as specified in the docs #151

New issue

Closed

opened 2026-10-18 14:09:27 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-18 14:09:27 +00:00

Owner

Originally created by @mildsenseofdoom on GitHub (Apr 10, 2026).
Original GitHub issue: https://github.com/open-webui/docs/issues/1175

I'm trying to get the guide here to work but can't, and would be grateful for any help.

What happens is:

The new chat appears after step 1
The user/assistant messages don't appear at any point (i.e. the chat is always at the "how can I help you today?" initial prompt)
If I follow through and do step 4 ("trigger assistant completion") then a correct response does appear as a browser notification, but not in the main chat interface.

One crucial point seems to be step 2 - I'm not sure why there's Java code there, or what to do with that. There's a note saying this step can be combined with the first step, which is what I've mostly been trying. In this case it seems like the POST data in step 1 should look a lot like in step 3, except (i) shouldn't have an ID as we've not been given one yet, and (ii) the "current_id" should be "user-msg-id", not "assistant-msg-id". Other than that, I think they should be identical, but then it's a bit strange that this isn't just given as the first step.

One point of confusion I have is the user/assistant message IDs - do I get to create these, or should I find an assigned ID somehow and fill that in? If I get to assign them, should they be globally unique, or just unique within the chat? I've tried a few times making sure they were fresh, with no difference in result. Similarly, I've just been using "session_id": "session-id" in step 4, though I'm less concerned about that as the chat is processed, it just doesn't appear in the UI.

Frustratingly, I did at an early point of experimenting manage to get the new chat to have the initial user message of "What is the capital of France?" so I must have done something right, I just can't seem to reproduce it! That was when I was just using curl on the command line, when I started to script it I couldn't get it to work - I can post the scripts I'm using if that would help.

Originally created by @mildsenseofdoom on GitHub (Apr 10, 2026). Original GitHub issue: https://github.com/open-webui/docs/issues/1175 I'm trying to get the [guide](https://docs.openwebui.com/reference/api-flow/) here to work but can't, and would be grateful for any help. What happens is: - The new chat appears after step 1 - The user/assistant messages don't appear at any point (i.e. the chat is always at the "how can I help you today?" initial prompt) - If I follow through and do step 4 ("trigger assistant completion") then a correct response does appear as a browser notification, but not in the main chat interface. One crucial point seems to be step 2 - I'm not sure why there's Java code there, or what to do with that. There's a note saying this step can be combined with the first step, which is what I've mostly been trying. In this case it seems like the POST data in step 1 should look a lot like in step 3, except (i) shouldn't have an ID as we've not been given one yet, and (ii) the "current_id" should be "user-msg-id", not "assistant-msg-id". Other than that, I think they should be identical, but then it's a bit strange that this isn't just given as the first step. One point of confusion I have is the user/assistant message IDs - do I get to create these, or should I find an assigned ID somehow and fill that in? If I get to assign them, should they be globally unique, or just unique within the chat? I've tried a few times making sure they were fresh, with no difference in result. Similarly, I've just been using `"session_id": "session-id"` in step 4, though I'm less concerned about that as the chat is processed, it just doesn't appear in the UI. Frustratingly, I did at an early point of experimenting manage to get the new chat to have the initial user message of "What is the capital of France?" so I must have done something right, I just can't seem to reproduce it! That was when I was just using `curl` on the command line, when I started to script it I couldn't get it to work - I can post the scripts I'm using if that would help.

bsakaguchi closed this issue

2026-10-18 14:09:27 +00:00

bsakaguchi commented

2026-10-18 14:09:27 +00:00

Author

Owner

@Classic298 commented on GitHub (Apr 15, 2026):

Hey @mildsenseofdoom 👋

Thanks for reporting this — you identified several real problems with the documentation. I've pushed a fix to dev that addresses all of them. Here's what was wrong:

1. currentId, not current_id

This was the main issue. The docs used snake_case everywhere in the history object, but both the backend and frontend expect camelCase. With the wrong key name, the frontend doesn't know which message ends the conversation thread, so it stays on the "How can I help you today?" screen.

2. Missing childrenIds field

The frontend renders messages as a tree. Each message needs a childrenIds array listing its child message IDs. Without this, the frontend can't walk the tree and messages don't render. Your user message needs to list the assistant message ID, and assistant messages need an empty array.

3. Message IDs are caller-generated

To answer your question directly: yes, you generate these yourself as UUID v4 strings before making the API calls. The server doesn't assign them.

4. The Java code in Step 2 was confusing

Replaced the Java-only Step 2 with a single combined Step 1 that creates the chat with both the user message and an empty assistant placeholder in one curl call. No more separate "enrich in memory" step.

5. /api/chat/completed is deprecated

The old Step 6 calling /api/chat/completed is no longer needed — outlet filters now run inline during the /api/chat/completions call. One caveat worth noting: outlet only fires when the request body includes both a chat_id and an id (message ID). The WebUI always sends these, but pure API callers using the standard OpenAI-compatible shape typically omit them. If your filters depend on outlet running for API requests, see the updated filter docs for a lightweight workaround.

The updated doc is now a cleaner 4-step process: create chat → trigger completion → wait → fetch result. I also added a "Common Pitfalls" troubleshooting table matching symptoms to causes.

The fix is live on our dev branch and should be deployed soon. Let me know if you run into any other issues!

@Classic298 commented on GitHub (Apr 15, 2026): Hey @mildsenseofdoom 👋 Thanks for reporting this — you identified several real problems with the documentation. I've pushed a fix to dev that addresses all of them. Here's what was wrong: **1. currentId, not current_id** This was the main issue. The docs used snake_case everywhere in the history object, but both the backend and frontend expect camelCase. With the wrong key name, the frontend doesn't know which message ends the conversation thread, so it stays on the "How can I help you today?" screen. **2. Missing childrenIds field** The frontend renders messages as a tree. Each message needs a childrenIds array listing its child message IDs. Without this, the frontend can't walk the tree and messages don't render. Your user message needs to list the assistant message ID, and assistant messages need an empty array. **3. Message IDs are caller-generated** To answer your question directly: yes, you generate these yourself as UUID v4 strings before making the API calls. The server doesn't assign them. **4. The Java code in Step 2 was confusing** Replaced the Java-only Step 2 with a single combined Step 1 that creates the chat with both the user message and an empty assistant placeholder in one curl call. No more separate "enrich in memory" step. **5. /api/chat/completed is deprecated** The old Step 6 calling /api/chat/completed is no longer needed — outlet filters now run inline during the /api/chat/completions call. One caveat worth noting: outlet only fires when the request body includes both a chat_id and an id (message ID). The WebUI always sends these, but pure API callers using the standard OpenAI-compatible shape typically omit them. If your filters depend on outlet running for API requests, see the updated filter docs for a lightweight workaround. The updated doc is now a cleaner 4-step process: create chat → trigger completion → wait → fetch result. I also added a "Common Pitfalls" troubleshooting table matching symptoms to causes. The fix is live on our dev branch and should be deployed soon. Let me know if you run into any other issues!

bsakaguchi commented

2026-10-18 14:09:28 +00:00

Author

Owner

@mildsenseofdoom commented on GitHub (Jun 7, 2026):

Just wanted to say thanks for looking into this - has taken me a while to come back to this but I did get it to work with this new information. Cheers!

@mildsenseofdoom commented on GitHub (Jun 7, 2026): Just wanted to say thanks for looking into this - has taken me a while to come back to this but I did get it to work with this new information. Cheers!

bsakaguchi referenced this issue

2026-10-18 14:10:47 +00:00

[PR #151] [CLOSED] Update faq.mdx #281