Change per_page for customers

I am trying to make a custom software for my team. and i need to pull the customers from the database into a website that i am doing.

when i pull customers from the customer pull request i only get 100 at a time, We have more than that i was just wondering if there is anyway i can change that.

i am using vuejs, and axios for pull requests

The responses should just be paginated, so you can grab more as need be.

likely you will have to make multiple requests in a foreach loop specifying the page number in each new request to get the next 100.
After you have the entire list in a single data structure, then display or process the list.

@Andy I find that when building tools there are many use cases where having the full list is better.

Yeah i have done that. it just slows down a the thing i want to do. its the worst thing in the world.

i just wanted to know if i could do one request and get all the customers but doesn’t seem like it.

That’s not realistic in many cases. Virtually every API will paginate at some point. If you have like 10,000 customers it’s going to run like junk, for example.

1 Like

Yeah i get that,

but don’t you think 100 as the max you can pull a bit low?

1 Like

I suspect there would be a way to asynchronously get each page, so if you had a grid to populate then your webpage could update in realtime as more data comes in.
In C# I would use await and async for this then update the datagrid.

Though I would probably get fed up with trying to get that approach right, and instead on the webserver running your webpage, I would have a cronjob run every hour (or less if you need) that pulls all the pages into a file or database table. Then code your webpage to pull from that file or database table. There isn’t going to be that many changes to your customer list in 1 hour or what ever interval you set.
You could also have a button on your webpage to force a sync.

@Andy I have worked with a lot of APIs.
Some awesome, some good, some woeful.
I have found the Webroot Unity API to the best.

The Webroot API for endpoints allows the http client making the request to specify how many records per page.
Documentation - API (webrootcloudav.com)

While the default is 50, the http client can change it.
This way it is the http client that decides its own level of tolerance for speed.

and notice for sites, there are no page sizes.
Documentation - API (webrootcloudav.com)

Yeah thanks for that. i think that is the best way to do it, thank you

No, your app should just paginate the results.

Actually what you are suggesting above here is accurate. You’d just have your app cycle the list async (or in sequence, it really wouldn’t take long in any event) and then process the batch however you need. This is extremely common.

May I ask what you are doing specifically that causes you to need to poll for all records of a particularly subset (like customers) on a regular basis?

@Andy
Using the Syncro APIs, we are working on a Windows Desktop App to manage as much Syncro data as we can, in a single app, integrated with data from other systems too. I am not a fan of Web UIs at all.
When the first trial version is ready, I will share widely.
If you would like a pre beta viewing, drop me a private message, or an email or give me a call and we can schedule a zoom/teams etc.

So if I understand correctly your goal is not not use the Syncro interface at all? If so, and all your updates are happening from the app you are building, I assume you can just update each customer ID in that case and just send things change by change, right? I might be missing some nuance here. Anyhow, I just find it interesting to know what folks are spending their free MSP time on :).

We have drifted a bit off topic…

Unfortunately the Syncro API isn’t comprehensive enough for this.

The general problem and goal is described in an article I wrote late last year.
Does anyone really know what’s going on? (technologydecisions.com.au)

Absolutely…

Actually a couple of years ago we already built a desktop UI for Webroot.
JCE-WebrootRecording #1 - YouTube
And have RangerMSP in the same App.
Jupiter Explorer - RangerMSP Account Add - YouTube
and RangerMSP intergrating with IT Portal.
Jupiter Explorer - RangerMSP integrating with ITPortal - YouTube

Syncro is a much better platform for running our MSP business compared to our previous Naverisk + RangerMSP stack. Syncro in some areas also comes closer to the goal outlined in the above article.
But there are many more feature requests we want/need to get closer to the goal in the article above than the features in Syncro currently provide, yet we cannot base our business decisions on the SyncroMSP Roadmap as we have no visibility to that roadmap.
So the choice for us, is do we accept being bound by the business decisions of Syncro and other 3rd party companies, or do we seek to do something about implementing the features that we want/need to more effectively serve our customers.

Spare time. Not free MSP time. There is a difference. :slight_smile:

1 Like

My free time was always my MSP time :). That’s a me thing for sure, though.

I’m curious, how many techs do you all have on staff currently? I’m trying to understand the challenges you face with having multiple techs and admin staff solely working with a custom app versus the app(s) as they were designed.

In all honesty the API will never be powerful enough to build the entire platform outside of the entire platform. That’s the same for any product for the most part, really. Custom apps can never support sustained growth in a space like this one, because the requirements change too rapidly throughout the various stages of an MSP’s standard growth cycle, which is why I asked the question above.

No one is working soley through custom apps to do 100% of everything that is possible in Syncro.
It is about trying to find ways to integrate/glue platforms together to create automations.
Each system has its design strengths.
But together there are many gaps when the systems are lined up against each other in a technology stack.

High on my list, but far from alone, is tracability of data access attempts.
Is there a place in Syncro where I can find a logged history of every user login attempt and every data access attempt?
No, there isn’t.

Do I wait for Syncro to make that happen (assuming it is even on the roadmap) or do I build a front end layer above the API, so that those job functions that are covered by the API can be covered by that layer.
It could be that a staff member’s duties can be 100% covered by the API, even if the API itself doesn’t cover 100% of everything that is possible in Syncro.
If, we can achieve that, then the staff member’s access to the Syncro data can be logged in a system, without giving that staff member access to their Syncro password, and without that Staff member having access to the Syncro API Key that the custom app uses.
This protects the customer data from the risk of that staff member going rogue in any way.

The OP started this thread about per_page data limits for customers.
The OP may have a staff member (or business process) that needs to make use of customer data in Syncro, but doesn’t add value to the business process by using their Syncro login.

As I demonstrated with the Webroot Unity API.
The Syncro API use of 100 records as a limit didn’t have to be that way. Other significant cloud systems made more flexible design choices in their API.
The API is the way it is, so we who a trying to improve our businesses through the use of the API have to cope with the arbitary limit of 100 records. One way of coping is to layer a automated caching mechanism on top of the API such as I described with a cronjob.