I have the same issue, vscode tells me what the issue is, just not how to solve it:
Power BI is Following Standards:
What Power BI Receives:
{"@odata.context":"...","value":[...]}{"error":{"code":"500","message":"..."}}
This is invalid JSON - it has two root objects. Power BI correctly rejects it.
Other Tools Would Fail Too:
The Server Should Return:
Success Case:
{
"@odata.context": "...",
"value": [
{
"UUID": "...",
"TotalEnds": 3730,
"Event": {
"UUID": "...",
"EventName": "..."
}
}
]
}
Error Case:
{
"error": {
"code": "500",
"message": "Exception occurred while processing OData request."
}
}
NEVER Both:
The server is mixing success and error responses, which violates all standards.
Power BI's Response is Professional:
Power BI gives you a clear, accurate error message:
"Invalid JSON. More than one value was found at the root"
This is exactly what should happen when receiving malformed JSON.
Bottom Line: Power BI is doing its job correctly. The OData service needs to be fixed by whoever maintains it (likely your Mendix team or backend developers).
The issue is that the OData service is returning invalid JSON. Even if you expose this as a regular REST service, you would run into the same problem: the response includes both successful data (value) and an error object at the same time. This creates two JSON roots, which breaks the standard and is why Power BI (and any JSON parser) correctly rejects it.
A good way to fix this is to add a server-side validation microflow. Validate the data before the response is generated, and if something is wrong, stop early and return only an error response with the proper HTTP status. If everything is valid, return only the success payload. This keeps the response clean, predictable, and standards-compliant.
If you set the Published OData loglevel to TRACE you might get more insights to what is causing the 500 error, for instance access rights in your domain or a duplicate key in your database.