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.
1 Like
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?
1 Like
I sent another email to support about the name field in invoice API. Received a standard no plans response.
We don’t all have simple MSP businesses. A large part of my business is contractor management, which Syncro doesn’t do. I hope it never does.
Too many software providers expand their product beyond manageable quality. Best to focus on one market and allow people to expand into different fields with API.
This ‘Name’ field is driving me nuts. Any invoice generated by Syncro doesn’t have a name field. All anyone generating invoices outside Syncro needs is a GET call for now. That cannot break anything in Sycnro, I’m sure its less than an hours coding.
1 Like
I am having the exact same experience with the ongoing Zapier problems. I am told by support that the issue isn’t “high impact” or that Zapier integration is still in “beta” so bugs there are not a priority. Yet if you consider the complaints of people here with the complaints of people having Zapier issues (see this thread: Creating new contacts in Syncro doesn't trigger Zapier & Office 365 sync) then you can see that there is a specific pattern of Syncro coming up with excuses for not addressing serious underlying issues with the API.
In fact, after repeated contact with Syncro support, they didn’t even want to admit the issue was on their end until Zapier (which has fantastic customer support) determined conclusively that the problem was on Syncro’s end. Meanwhile, over the last year or so that Zapier integration has been broken, Syncro has been rolling out countless new features. Many of these features are nice but not nearly as fundamental as having a working API. It feels like Syncro is not listening to the needs of its users, and is focusing too much on growing its user base rather than ensuring the needs of its current users are being met.
1 Like
The API needs some love and attention. It is feeling neglected.
2 Likes
@garyh I hope others will continue to chime in here so that the development/leadership team at Syncro pays attention. It’s so frustrating not to be heard, especially since there are probably so many other people having similar issues who haven’t yet spoken up.
1 Like
I feel like at this point, it’s very apparent that this is a highly requested feature. Hopefully this is something they put some time into fixing. Note - I said fixing, not adding. This isn’t a MISSING feature, its a broken/unfinished one.
This comment is completely inaccurate.
Why would you say you believe we didn’t add it to our API? Before you go on detailing how easy everything is to add, please check to see if it’s there first :). You can test any API call live right in Admin Settings > API > Documentation section (Swagger). The last_boot_time is present, and you can see that by testing a simple GET call on the Asset endpoint.
While we will always be making incremental improvements to the entire platform, we won’t be taking an API-first approach. That doesn’t mean improvements won’t come, nor does it mean every feature release will be included in the API. Some won’t be added for security reasons (running scripts, for example), and others are designed for exclusive use in our UI (like Chat).
Those are simply example values to show the schema. It says as much right in each pane. If you want to see a full accounting of what may be presented there, simply run the call…
Perhaps I’m merely a bit weird, but I’m expecting the example values to provide an accurate and current example of the response including the full schema structure of the response so I can design my classes in my code according to the expected structure of the response. Rather than a whole lot of trial and error.
To simply run the call, I have to first navigate away from the page to generate a API key with the appropriate permissions, then record that key somewhere secure then come back to the swagger page, enter in the subdomain, enter in the API key, oh, then I run get_customer_assets…is it in that enpoint, or do I need a id and use get_customer_asset{id} instead, right lets try that one…nah not there, lets try all the others just in case it was unexpectedly put in a different endpoint.
Why is it so hard to accept that the API documentation should be maintained and up to date with the capabilities of the API.
Many other vendors seem to accept this as a given.
You’d run it against any specific asset (ID) if you were attempting to see if any given information was present there. I assumed you had a key handy already since it sounded like you were a heavy API user.
At any rate, the feature is present in the API.
I started off spending a lot of time developing against the API, but soon realised how terrible it was not having a proper query/filter mechanisms (such as I want a list of all the customer ids whose business name starts with Pro or The or Au). If you try this, then it returns customers with those strings anywhere in the name, but not at the start.
So I went off on a tangent to build a system to buffer the data in a proper data storage system that had such capabilities, which then sent me off on a tangent to securely store the API keys in an encrypted format so I didn’t have any plain text record of any of them.
So no I don’t keep API keys hanging around to copy and paste into Swagger. That is akin to hanging front door keys on the hook next to the door bell.
Awesome, the feature is in the API…and know you understand why I didn’t believe it was several posts back. .
But until the new feature is properly included in the API documentation for all to read, the feature is not finished being implemented (from a software engineering point of view)
Please finish the last boot feature.
Given Syncro is using Swagger, it might be worth while for you to read the Swagger document on how to document the Syncro API, and demonstrate what good API documentation looks like.
OpenAPI Specification - Version 3.0.3 | Swagger
and why documentation matters.
What is API Documentation? | Swagger Blog
1 Like
Hey Andrew,
There are no planned updates to the last boot feature at this time in regard to the API.
I respect and appreciate you taking the time to chime in on this thread. I understand that moving to an “API First” approach would be a very large undertaking. I also (somewhat) understand the desire to omit certain functions for security purposes…
That being said, there are still large portions missing, such as ANYTHING to do with policies or folders. You can neither enumerate, list, or modify policy folders within customers, nor can you even see what folder an asset is in from the API. This would be less of an issue if Syncro allowed you to apply multiple policies to one folder, but since it doesn’t, nesting is required to achieve more than one policy on a group of assets. This has been a very very large pain point for us, as we have over 5k assets. The inability to automate categorization has caused a lot of manual work for us, as we need to manually categorize workstations and servers into their own folders with respective patch/software policies applied. This has to be done PER CUSTOMER…
This is all to say that Syncro is a great product, and what it does do, it does well. It has some shortcomings that a fully featured API would absolutely make up for, since we could automate these things ourselves, reducing the need for more functionality in the GUI.
1 Like
First goal would be to document properly what the API does at the moment. As we see with the latest enhancement to the API (that we know of), that being the last_boot_time which was not documented in the API documentation and the update to the API to include last_boot_time didn’t even make it into the Release notes.
This
Should have included mention that last_boot_time was added into the API.
Documenting the current API takes zero expensive developer resources, is zero risk to the stability or security of the current platform and zero testing time.
Merely a resource is required that can run the API and update the documentation.
Second goal would be to improve the API to include all the missing bits such as policies folders, and all the other feature requests that are API related.
Last boot time has always been in the API. This release note is just referencing the fact that we took an existing feature and made it more prominent in the UI.
ahhh, fair enough.
This is so difficult when the documentation for the API is so poor.
The documentation for Get Asset by ID (aka /customer_assets/{id}) says that the 5 fields below are an example response to expect.
This is completely useless documentation.
Why isn’t last_boot_time in the example response?
{
“properties”: {
“id”: 0,
“asset_id”: 0,
“account_id”: 0,
“created_at”: “string”,
“updated_at”: “string”
}
}
Looks like the lack of functionality in the API is intended, because Syncro does not trust / believe its users know how to use APIs.
I think the Syncro team should take a really long hard look at how they determine what features get added to the product. It’s very clear now that Syncro is making an explicit stance to leave features out of the API because they know better than us.
This should serve as a very heavy point of consideration for anyone looking into the product.
2 Likes