Any help that can be provided to my questions/queries would be greatly appreciated. The company I work for has a client that may require us to obtain some data extracts from Kinetic (software they are using). I have been tasked to understand the feasibility of extracting data from Kinetics API library.
From reading several posts on this forum and Epicore’s website I have come up with a list of “assumptions”.
Any knowledge as whether my assumptions are correct or not and any corrections of my failed theory’s would be greatly appreciated.
It seems that Kinetic can be hosted in either a localised environment or within an online cloud environment. Is this the case?
It seems API connections can be performed regardless of the type of hosting (subject to the accessing local networks for localised implementations). Is this correct?
Does the API connectivity have to be specifically setup/configured or are they available as a default installation of Kinetic?
Can the API connectivity be segregated to only allow Read-Only (GET) for selected API keys/tokens or are all features within the library available for all API users?
I am assuming that to extract large volumes of data from API calls will require coding from us to make several calls and extract x records at a time. Are there limits inbuilt to prevent high volume API traffic within time periods (e.g. some systems we connect to have limits on the number of API calls ad the volume of data per call)?
Does anyone have any other general pointers or advice that I should be aware of before I explore the API option further?
Many thanks in advance for any help or advice that could be offered
Welcome Chris!
You have come to the right place. I am no pro here, but I can answer some of your questions.
It seems that Kinetic can be hosted in either a localised environment or within an online cloud environment. Is this the case?
Yes, there are several options for self hosting, cloud hosting, and shared cloud hosting.
It seems API connections can be performed regardless of the type of hosting (subject to the accessing local networks for localised implementations). Is this correct?
Yes, API comes with Epicor. There may be some restrictions for some cloud users. Not sure here.
Does the API connectivity have to be specifically setup/configured or are they available as a default installation of Kinetic?
Yep. It is available out of the box. Once you setup your API key in Epicor you are good to go.
Can the API connectivity be segregated to only allow Read-Only (GET) for selected API keys/tokens or are all features within the library available for all API users?
Yes, You can use access controls to allow specific groups or users, and I think you can force only GETs.
I am assuming that to extract large volumes of data from API calls will require coding from us to make several calls and extract x records at a time. Are there limits inbuilt to prevent high volume API traffic within time periods (e.g. some systems we connect to have limits on the number of API calls ad the volume of data per call)?
I have never had any issue pulling data out with the API. The limitations will come from your end point and the data you are pulling. For extremely large sets, there may be better ways. I’ll let some other pros chime in on that.
There is a great REST API helper page that will build all the rest calls to your BAQs. This has been extremely helpful for me as I get to understand more about REST calls, Epicor APIs, and JSON. You can use it in both the Pilot database, and the Live database, making testing new BAQs/REST calls easy.
Good luck!
You mentioned the REST API help page.
Do you have a link to it and if so, is it available publicly as we are not a user of Epicor. We will be working with our client as a consultant and extracting data for analysis
I don’t think it is available publicly, as it targets your specific database. In this case, this is a link to our live database. I think everyone pretty much has the same link, so if you have Epicor installed, this should get you there. Though you do need a user account, and appropriate security settings to mess with API.
Edit: `removed to protect @NateS` <-- That link was specific to YOUR instance - klincecum
Hi Nate,
Thanks for the link.
I will have to try and get some user access from the client if the proposal progresses.
Thanks again for all your help, some great information there that is really useful
Chris
Each API key can be given its own permissions, down to the specific method call. So you can set it to only be able to access read methods. I’m also a big proponent of wrapping external calls into “functions” which are libraries of custom methods within the ERP itself which can be designed to be
read-only
have extra safety on writes
aggregate data to minimize the number of calls
streamline the inputs/outputs to only what’s needed.
chain multiple internal operations into one call.
I do not call the standard “business object” methods from outside the system. They can get…verbose. They also aren’t always flexible enough to do what I want.
I’ve pulled tens of thousands of records in one call while testing. I have production systems that can poll multiple times a second (albeit infrequently). The application uses the API to talk to itself. It’s pretty robust.
Thanks Kevin! I didn’t see any personal identifying information in there, and it did not include our Site ID. What is specific in that link to our company?
