Yes, this is due to an architecture that underlies pretty much all of Mockito.
The big idea in Mockito, as I gather, is the ability to express behaviours in ways that feel reasonably natural:
when(myMock.doSomething(value)).thenReturn(result)
Actually, when executed, the byte-code is equivalent to the following:
Object tempResult = myMock.doSomething(value);
when(tempResult).thenReturn(result)
The magic is from the fact that the myMock object managed by Mockito. Mockito intercepts the call to doSomething() and change its internal state to expect further configuration (in that case, it becomes aware of the when() clause and then knows that it will next receive the result value).
Now, consider your code (removing the argument matchers):
when(restHelper.post("asd", config.apiEndpoint())).thenReturn("response");
as per the example above, this is actually equivalent to:
String endPoint = config.apiEndpoint();
String tempResult = restHelper.post("asd", endPoint);
when(restHelper.post("asd", tempResult)).thenReturn("response");
On the first line, Mockito intercepts the call to config.apiEndpoint() and change its internal state to expect further configuration.
On the second line, Mockito intercepts the call to restHelper.post, and... fails, as it was expecting something like a when(). Instead, you instructed Mockito to configure 2 mocks at the same time.
Now, I realise that the error message you got mentions argument matchers. That's OK. It only means that Mockito failed on a slightly more unusual combinaison of arg matchers and mock configuration. It's a bit hard to describe that, but the idea is exactly the same.
Personally, I like using only hard-coded values when configuring mocks anyway. I actually have no problem copy/pasting the same primitive values as many times as necessary, because I find them to make tests more obvious to read.