REST API sticky sessions

Hi Tarmo,

Have you seen this support article: REST API calls may suddenly fail around January 2024 and miss cookies (site.com)?

There is some additional content here, although I don't believe it's causing this: Authenticating to the M-Files Web Service (REST API)

Hi Graig,

Yes I have checked both of the articles, and tried to add the line wr.ServicePoint.Expect100Continue = false;

but I do not get any cookies within the authentication response. Maybe I should send the code to someone to check it out? I have no previous experience of this API, and this is the first time I look at the code and I do not even know if the url and request parameters are correct, and if we should use some other kind of approach using the API. But I assume it has been working before. We are using .NET Framework 4.8.

I don't think that I've specifically seem this happen, outside of the scenarios above.  Can you show where you added that code?

If you're continuing to have problems then it may be worth reaching out to your partner or account manager to see whether they can provide some additional support via a call or similar.

Hi, this is the authentication code to get token

This is the GET request to get the data

I have tried to add the request.ServicePoint.Expect100Continue = false; line to both of them, and  also the CookieContainer object but that did not make any difference. Maybe you can better see where the problem is. Or I can contact directly to anyone of your consultants if needed.

Hi, this is the authentication code to get token

This is the GET request to get the data

I have tried to add the request.ServicePoint.Expect100Continue = false; line to both of them, and  also the CookieContainer object but that did not make any difference. Maybe you can better see where the problem is. Or I can contact directly to anyone of your consultants if needed.

Can you use a tool like Telerik Fiddler to record the raw request and responses and take a look?

As this is a peer-to-peer forum, if you have a service contract or similar, it may be quickest to use that to speak to some of our consultants directly.

Equally: I too will struggle to respond this week due to our global conference. 

Yes, I am trying to find out who is the consultant for us. I think for us as a partner who has implemented the API for the end customer should have a named consultant. But I now have some additional information via Fiddler. This is the raw response of the GET request:

This looks to me like an issue with the credentials, rather than anything else.

Hello Graig,

It now turned out, that our customer is currently re-routing their M-files REST API via another web service, so that is the root reason for this malfunction. We will continue studying the case after the re-routing is complete.

Thank you Graig for your help and advice. I will return to the issue if necessary, but I think from now on we will be communicating with the new web service interface and not directly to the M-Files server.

Br. Tarmo

It sounds like you might be experiencing an issue with the multi-server mode https://developer.m-files.com/APIs/REST-API/Authentication/#multi-server-mode-considerations . Based on the code snippet, it seems like you're making a simple API call, but when the multi-server mode is active, you need to establish a session for your REST calls, similar to this:


After receiving the response, make sure to save the cookies for each subsequent call. This approach should help prevent the UnauthorizedAccessException. Even if you have a valid token, not including the cookies in your call will likely result in that error response.

I hope these small examples can guide you a bit on the change you need to make, but from what I see, you've already solved it in another way.