1
Build 9088 API Changes AGAIN!!
Problem reported by Bruce - 11/19/2024 at 3:53 AM
Submitted
Since upgrading from build 9056 (Oct 18, 2024) to build 9088 (Nov 18, 2024), our control pane can no longer retrieve email accounts using the API.

Can you let me know what API changes have been made to the API?

Thank you.

20 Replies

Reply to Thread
0
Kyle Kerst Replied
Employee Post
A review of our release notes reveals no API related changes between 9056 and our latest:


I recommend submitting a ticket with the control panel creator and one with us if you need assistance troubleshooting that further.
Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com
0
Bruce Replied
I didn't find any API changes in the log files, but it's not uncommon for API changes to be implemented in SmarterMail without being mentioned in the release notes.

Could you check with the developers if they made any changes that they didn't list in the release notes?
0
Jack. Replied
Hi Bruce?

What control panel are you using?


0
Bruce Replied
MSP Control.

For the time being, I have rolled back to Build 9056, which works with MSP Control.
0
echoDreamz Replied
Thanks for letting us know Bruce, we dont use MSP Control, but we do have our own control panel. So, waiting to hear what has changed.
0
Kyle Kerst Replied
Employee Post
I wanted to let you know that I've set up one of our support guys with a test environment to see if we can get this control panel setup for testing. If we're able to replicate the issue in-house we'll get a task escalated to development right away.
Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com
0
Bruce Replied
Thanks Kyle.
1
Douglas Foster Replied
We have noticed that a previous SmarterMail bug has created duplicate security providers for the same Active Directory server, so different users are now on different GUIDS and we have the same name listed multiple times.   If you have the same symptom, it would explain why some users are not accessible from you control panel, and it has nothing to do with API changes, just dirty data.   We opened a ticket on this issue tonight.
0
Bruce Replied
Thank you, Douglas, but this is not the issue. All mailboxes cannot be edited from MSP Control on SmarterMail build 9088, and rolling back to version 9056 resolves the problem.

There seems to be a problem finding the domain when you try and edit a mailboxe as you get an error that the domain cannot be found.

The MSP Control developer working on the SmarterMail provider believes he has narrowed it down to an issue with the get-user API call, but he needs more time to look into it.
1
Jack. Replied
@Bruce 


The SolidCP provider for SmarterMail has been updated, we are currently doing some testing.
0
Bruce Replied
Thanks, Jack,

While SolidCP and MSP Control are both forks of WebsitePanel, MSP Control has been rewritten in ASP.NET 8 blazer and therefore, the SolidSP provider for SmarterMail will likely not work in MSP Control.
0
Derek Curtis Replied
Employee Post
Bruce,

Are, or were, they possibly using the legacy API for SmarterMail? I ask as the only changes I can see for the API relating to GetUser were documentation related, not changes to the call itself. 

And, just to make sure I wasn't missing anything, I asked the SmarterMail team and they said the same. 
Derek Curtis COO SmarterTools Inc. www.smartertools.com
0
Bruce Replied
MSP Control doesn't use the SmarterMail legacy API.
0
Webio Replied
@Derek: This might be related to some changes in API for:


Is there any chance that clientId was added somewhere in the way and in latest build is required as a param?

Switching API call from mentioned sysadmin part (POST) of API to (GET):


for fetching user data probably fixed this problem.
0
Derek Curtis Replied
Employee Post
ClientID was added to that call almost 10 months ago, so no new changes there between 9056 and 9088. Also, if I understand the question/suggestion, changing the SysAdmin call to a GET is what we call a "breaking change" for the API. 
Derek Curtis COO SmarterTools Inc. www.smartertools.com
0
Bruce Replied

Webio has resolved the issue with the SmarterMail provider in MSP Control.

 

The problem originated from the first API method mentioned below, which changed or broke between versions 9056 and 9088. This alteration prevented mailboxes from being edited in MSP Control.

 

https://mail.smartertools.com/Documentation/api#/reference/SmarterMail.Web.Api.SystemAdminSettingsController/GetUser/post

 

An alternative SmarterMail API method is now being used to achieve the same results, ensuring that SmarterMail functions properly in MSP Control.

1
Webio Replied
@Derek: I had to switch to completely different method and not just simple POST -> GET which IMHO if would be true then still this would be a breaking change because it would break things right?

Bottom line THIS method (POST - sysadmin account):


returned:

Domain does not exist.. error

So maybe it is something to check on your end and see how this method behaves.

Switching to this method (GET with Domain bearer token authentication):


allowed to fetch user datails while providing the same mailbox as first method.

EDIT: Does ClientId param for metioned POST method is required? Does this change (adding ClientId param) 10 moths ago was somewhere documented?

EDIT2: I've updated one of my SM instances to latest build and yep - take a look at screenshot from REST client app:

while the same email account details can be fetched using domain get user method
0
Alessandro Pereira Replied
We are having the same problem after updating.
/api/v1/settings/sysadmin/get-user

The POST method stopped working and now requests the clientid field

Now it returns the error:
{"message":"Domain does not exist.","success":false}

That's problematic,
let's update our panel to the GET method
0
Webio Replied
IMHO this is not related to clientid being requested since error is not telling about missing param but about domain which does not exist which is not true because domain from email param does exist in SmarterMail instance to which API request is being made
0
echoDreamz Replied
Can confirm here as well, the old

client.ExecuteRequest<GetMailAccountResponse>("settings/sysadmin/get-user", new { email = accountName }, adminAccessToken, Method.Post);
No longer works and returns "Domain not found" - This has been working for a while now. Also, the 

api/v1/report/user-stats/{startDate}/{endDate}
UPDATE: the stats requests started working out of nowhere, but is still wanting a clientId, seems to be OK without it however. What is the clientId param for?

Reply to Thread