You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, KoboToolbox responds with a generic HTTP 500 Internal Server Error in several scenarios, including but not limited to:
When required information is missing or malformed in the request
When a file size limit is exceeded
When there is any kind of conflict during submission or processing
In all these cases, the 500 error is returned without a descriptive message indicating the cause of the error.
Why this matters:
This behavior makes it difficult for users and developers to understand what went wrong and how to correct it. It also hinders the ability to provide accurate bug reports or support requests, as there is no visibility into the underlying issue.
Suggested improvement:
For every 500 error (and ideally for all 4xx and 5xx errors), KoboToolbox should return a descriptive error message in the response body. This message should clearly indicate the reason for the failure, such as:
"File size exceeds the allowed limit of X MB."
"Missing required parameter: submission.xml."
"Conflict: Submission with this ID already exists."
Expected benefits:
Improves user experience and reduces frustration
Helps users and developers correct submission issues more efficiently
Leads to more useful and specific bug reports, improving the development feedback loop
Aligns with best practices for API error handling
We hope this can be prioritized as part of ongoing usability and developer experience improvements.
The same issue occurs when submitting via the API. If there's a problem with the submission, the response is an HTML error page instead of a structured error message, which makes debugging more difficult.
Validation errors are returned in XML. Can you describe how you test it? For example, when I test conflicting submissions, I do receive an XML.
500 errors are a different story.
Activity
[-]Improve Error Messaging for HTTP 500 Responses[/-][+]Improve Error Messaging for Error Responses[/+]nicopace commentedon Jul 22, 2025
The same issue occurs when submitting via the API. If there's a problem with the submission, the response is an HTML error page instead of a structured error message, which makes debugging more difficult.
noliveleger commentedon Aug 5, 2025
Validation errors are returned in XML. Can you describe how you test it? For example, when I test conflicting submissions, I do receive an XML.
500 errors are a different story.