[Question]: Embedded website Agent fails with 405 errors
Self Checks
- [x] I have searched for existing issues search for existing issues, including closed ones.
- [x] I confirm that I am using English to submit this report (Language Policy).
- [x] Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
- [x] Please do not modify this template :) and fill in all the required fields.
Describe your problem
description
I am trying to use the Embedded Agent feature (embedding website/iframe). While the Agent works perfectly inside the RAGFlow Canvas/Playground, it fails to function when accessed via the shared/embedded link.
The embedded frontend sends requests to /api/v1/agentbots/..., butthe backend returns 405 Method Not Allowed.
Steps to Reproduce
-
Create an Agent in RAGFlow.
-
Go to the "Embed" tab and copy the "Embedded Website" link or iframe code.
-
Open the link in a browser.
-
Attempt to send a message to the agent.
-
The webpage crashes or hangs, and the browser console shows 405 errors.
snipaste
The 405 errors when using Embedded Agent via shared/iframe links are caused by backend API method restrictions and authentication requirements. The /api/v1/agentbots/<agent_id>/completions endpoint only allows POST requests with a valid API token in the Authorization header, and /api/v1/agentbots/<agent_id>/inputs only allows GET requests with the same requirement. If the HTTP method or token is missing or incorrect, you'll get a 405 or 401 error respectively. There is no special handling for embedded/iframe contexts—these endpoints work the same way as in the main interface, so the same rules apply source.
Embedding agents via iframe only works for agents that do not require input parameters in the Begin node. If your agent needs variables or files as input, embedding via iframe will not work due to security restrictions—use the API or Python SDK instead source.
Troubleshooting checklist:
- Make sure the embedded agent does not require input parameters.
- Use the correct HTTP method for each endpoint.
- Include a valid API token in the Authorization header.
- Confirm agent/session ownership matches the API token.
- Ensure frontend and backend versions match and clear your browser cache if you recently upgraded.
If you follow these steps and still see 405 errors, double-check the network requests for method and token issues, and verify the agent is embeddable source.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@dosu I do use POST to request, while the console shows 200 OK, the message is 405 method not allowed
This happens because the backend wraps all errors—including 405 Method Not Allowed—in a JSON response with HTTP 200 OK, so the browser shows 200 OK but the actual error is in the response body. This is standard for all API endpoints, not just embedded/iframe requests. The 405 in your response body is the real backend error, usually triggered by an unsupported HTTP method or a routing mismatch, even if you are using POST as expected.
To troubleshoot, double-check the full request details in your browser’s network tab: make sure the Authorization header is present and valid, the endpoint URL is correct, and the agent doesn’t require input parameters (which aren’t supported in embedded mode). If everything looks correct, sharing a sanitized request/response example could help pinpoint the issue.
Reference: backend error handling
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@dosu Here is an example curl -X POST 'http://localhost:9090/api/v1/agentbots/265478a4b5a711f0a015d66e8ab70620/completions' -H 'Authorization: Bearer diYjU1OTEwMGQzZTExZjBhZjg3NjZhMz' -H 'Content-Type: application/json' --data-raw '{"query":"test","inputs":{},"session_id":null}' {"code":100,"data":null,"message":"<NotFound '404: Not Found'>"}
Is the ragflow_server port 9090? As defualt, it should be 8090, shouldn't be?
How did you get the agentbots url? I have tested the agents url and everything is fine.
@KevinHush I previously modified the configuration in the .env file due to a port conflict. Now it uses 9090 as the port The corresponding modifications are listed below. Could you please advise if these changes might affect my overall configuration or system behavior?
The Docker image version I am using is infiniflow/ragflow:v0.22.1.
Original .env Configuration
DEVICE=${DEVICE:-cpu}
SVR_WEB_HTTP_PORT=80
# COMPOSE_PROFILES=${COMPOSE_PROFILES},tei-gpu
My Modification
DEVICE=${DEVICE:-gpu}
SVR_WEB_HTTP_PORT=9090
COMPOSE_PROFILES=${COMPOSE_PROFILES},tei-gpu
@Magicbook1108 The AgentBot URL was sourced from the same configuration location. When using the v21.1-slim image version, the functionality worked correctly. However, after upgrading the version, the service suddenly failed.
My primary action was modifying the .env file; no other application code or configuration files were altered.
Do you have any suggestions regarding potential causes for this sudden failure following the version upgrade?
I don’t think this issue is related to the ports you modified, since you can still access the agent page and obtain the embedded URL successfully.
Right now, I’m focusing on the 405 error. Could you describe in more detail how you performed the upgrade? This will help determine whether the problem was introduced during the update process.
I don’t think this URL is intended to be used through the HTTP API. Normally, you would either open the URL directly in a web browser or copy the entire embed code into an .html file and view it in the browser.
@magicbook1108 Here is my step:
- Version Update & Configuration Check I followed the instructions in the official documentation regarding the upgrade:
I first updated my local GitHub repository.
I then used git checkout -f v0.22.1 to switch to the target version.
My primary change was modifying the necessary parameters within the configuration files (i.e., those previously discussed). I carefully compared my local configuration against the clean v0.22.1 codebase and confirmed that only parameter values were altered; no other source code files were modified.
- Initial Startup Anomaly (For Reference) During the initial launch, the startup time was significantly long, resulting in a 502 Bad Gateway error. Upon investigation, I found this was due to missing Python third-party dependencies (I can't recall the exact library, but I remember it was related to PyTorch or cuDNN) inside the GPU server image, slowing down the server application startup. The system became accessible after the installation completed.
I mention this issue purely for context, but I do not think it is related to the current 405 API problem.
- Sandbox Feature Removal Additionally, since I had previously experimented with the 'sandbox' feature with poor results, I made sure to remove the corresponding dependencies and configurations related to the sandbox functionality when switching to the v0.22.1 version.
These are all the changes and anomalies I can recall related to the upgrade.
- here your screen shot saying 405
- pytorch won't be downloaded except you are starting from gpu
If 405 isn't your issue then what's the issue? 404 can't open the embeded webpage? You should try it in the web browser I guess
@magicbook1108
I apologize if my previous answer caused any misunderstanding. What I meant was that the PyTorch-related installation issue is not my primary concern; I only mentioned it to ensure I hadn't omitted any operational details.
My actual question definitely remains the 405 issue.
I want to confirm that I did test this in the web browser, and the Method Not Allowed error is precisely the information I saw when the page froze, as checked using the F12 developer tools.
Given these conflicting configurations or potential update anomalies, would you suggest that I perform a clean reinstallation to eliminate all potential interfering factors?
Thanks a lot !
A clean reinstallation is definitely the simplest approach if there isn’t much data to preserve. That said, I will still attempt to investigate the 405 error to identify the actual root cause.