API Feature parity needed/API unfinished

Seems like anytime this is requested, it basically gets ignored, or replied with “We will consider this if we get more requests”, and then ghosted. Hoping to shed some light on why this is such a necessary feature for an application like Syncro, and show that it IS a highly requested feature

The Syncro API is decent enough, and the parts that are present, are documented well.

That being said, there are SO many things you simply cannot do.

Here is a basic, likely common use case:

We have over 5k endpoints. We deployed Syncro to all of them via a mass deploy script. This filters them into their customer, under the default policy folder. We now need to setup policies for user workstations, and servers, as these would obviously not have the same policies. The solution would be to create policy folders, move assets into them, and assign policies. Easy.

I can create a “Servers” and “Workstations” folder, and move things into them, then assign policies to them in the GUI, no problem. Works great. Now to do the other 170 customers, some automation would be great, except not a single one of those things can be done in the API. You cannot create/view folders, move assets into folders, or assign policies to assets or folders from the API.

This is among many other things that are blatantly missing, that can be done just fine in the web page.

I created a support ticket on this, assuming it was a bug, but was met with this response:

I spoke to our product team and this is not currently planned but something we’d certainly consider if we continue to hear requests like this.

Here are a few requests I’ve seen in my brief research:

I am sure there are many more requests that didn’t come up in my 5 minute search of the feature request forum.

Syncro - If you’re reading, this is something we really need.

3 Likes

Yes that would be lovely

1 Like

Hey - Ian from Syncro here. Yes, agreed. There’s just a lot of work that could be done and limited resources :slight_smile: I’m tracking all of these though!

Thanks for the feedback,

Ian

1 Like

Hi @chase1, Dale here, Director of Product. We are committed to improving the API and making it a first-class citizen in the platform. In a recent review, we mapped many gaps and identified clear paths that will take some time to implement. Just know the value of a robust API is understood! Look for more updates soon.

Dale

1 Like

Like OP said probably the BIGGEST source of frustration is policy management, so being able to create policy folders, move assets between policy folders, and assign policies to folders and computers would be.

It would be interesting to do a pole of some sort listing all of the things the api is missing and allowing people to prioritize the list.

1 Like

Maybe a shift of focus to have your web app use the same API to do it’s business would open the possibility for us to do ours. :slight_smile:

2 Likes

Hey I was in one of the many request :smiley: I have many more request for more API control.

I will say and play devils advocate and say it does take time to get these out and make sure they are safe without risk. So some things would need to be under watch list and log tracking. So it would not be as simple as adding more API fields. Some thought would have to go into each addition base on the request/need for that request. I think their main focus is on moving to AWS though so it will be a while before we see any changes there, sadly.

With that said, there are also better ways they could attack some things as well that could have less need for API calls. Either way, agree it needs to be added at some point if we can please:)

For example, in the case of the OP - it would be better if we could have a Template design that we can apply to new customers. This would setup all the folders and policy for that customer without the need to go into each account to create and name them correctly over and over again.

It also would be better to have the ability to add more than one policy to a folder. This would allow for more flexibility without the need to create different policy for every situation that might need to be address. It also helps break up complex policies as well into more basic rules. Such as for example, one that deals with AV-A and another that does AV-B that can be broken down into managed, unmanaged, etc. Reducing the need for 6 different folders down to 2.

1 Like

Precisely. Looking at the dev console, it’s not hitting the same API endpoints when you make changes that do have API parity

All amazing points. Originally, I was hoping to have a good way to auto sort workstations/servers. Seeing there was no automatic template features, I fell back to the API, and was immediately blown away by how much is missing from it.

Yeah there is a lot missing from the API that the web portal can do. You guys should take a look at the API for Pipedrive. We use that for sales and their API can do just about everything their web portal can do. I love it. A very good example of what an API should be. And webhooks. Don’t get me started. A lot of the webhooks in syncro never fire. And so many are missing. Adding a customer, there is a webhook that doesn’t work. Modifying one? No such webhook. Deleting a customer. No such webhook. These are basic integration components all web apps need. This is why Zapier is so limited with Syncro. So programmers and non-programmers are limited.

I would suggest the first place to start is to change the Soft Dev first principals for the code base.

When considering the design of any new feature or any bug fix or any minor/major update, that Syncro follow an API First approach.
Understanding the API-First Approach to Building Products (swagger.io)

In parallel, in my view, you should also consider looking at the authentication mechanism of the current API.
Head over to the documentation for the Webroot Unity API for an example of a much better authentication mechanism than Syncro currently uses.

3 Likes

This is a great approach. It ensures that the APIs and documentation is not left to be an orphan child.

I was the one that posted about the API name field.

I built from the ground up an integration to Dynamics 365 Customer Service, Field Service, and Project Operations. Works fantastic as now I manage most of my data in D365 and use Syncro for RMM ticketing and automated invoicing (Just invoice generation. My integration pushes Invoices to D365 and then to my Accounting software which actually sends the invoice. Makes the accountant happy.)

Only one problem. That darn Invoice NAME field API still does not exist. A workaround has been to take a few lines from the first line item and use that as the invoice name. Its not neat.

Where is that invoice name field??? Why was it never included in the first place?