So what, exactly does that error tell us about the root cause? The important bits in really identifying the root cause of the failure are the parameter values passed to that function, not the signature of the function.
And yes, I know it requires some extra work because Java/C#/Python/etc. are all brain-dead about error messages, the worst of which is the “ClassNotFound” error, where the message fails to tell anyone which class was not found. ProTip: look up the Pragmatic Programmer series on Java and how they resolve the ClassNotFound error by overriding the ClassLoader class - pretty slick. It might take some monkeying with the Exception handling to extend/override the Exception, spit out the parameters in the MCEBuddy log and then re-throw the original exception.
Similarly, in this case, we don’t know which parameter caused the failure (or whether it was a simple network timeout) or if there was an API failure with an error code. Although if there is an error like we’re seeing here and not an error code returned by the API call, then that should be a (minor) coding issue on the MCEBuddy side, not a lack of response on the API service side (as that would be an expected (empty) non-response response - i.e. this null response from the API).
So what is the root cause, then?