Not quite a breaking change, but in some specific scenarios it may be.
In short, before when an invalid or expired access token was passed this way:
GET /api/domain/odata/Crm_Customers?$top=10 HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE2NTQwNzA5MTQsImV4cCI6MTY1NDA3NDUxNCwiaXNzIjoiSGVsbG8gZnJvbSBteSBJZCBzZXJ2ZXIiLCJhdWQiOlsiRG9tYWluQXBpIiwic2VjIiwidXBkYXRlIl0sImN1c3RvbV9jbGFpbSI6IkhlbGxvLCBob3cgaXMgaXQiLCJjbGllbnRfaWQiOiJpbnRlcm5hbC5hcGkuZGJob3N0L2FwaSIsImNsaWVudF9zeXN0ZW1fdXNlciI6InVzZXIiLCJjbGllbnRfZGIiOiJFMV9ERVYiLCJqdGkiOiJZYU44WTNzVTVWNm9xN3VxNjVuSTFBIiwic2NvcGUiOlsiRG9tYWluQXBpIiwic2VjIiwidXBkYXRlIl19.Pzut0EC0ghG6Joy17VYPgq4X8eysEy9fMu01u61w9Nk
the following error was returned:
This is not a very informative response code, is it? That's why the error is now returned as:
Far more self-descriptive.
Does this change affect me?
Yes, if you have error handling for such a scenario and you expect to receive exactly HTTP 500.
What to do if this change affects me?
Just adapt your error handling to HTTP 401.
More information is available in our official documentation: