API feature request

I feel like this isn’t much to ask but can we get a response back from the REST API with what variable is missing or what data isn’t the right format?

Cause right now it just says: “Unable to deserialize entry”

Even though the JSON is good.

It’s mind numbing dealing with these issues. Almost every REST API I’ve ever worked with with will respond with why the request is bad.

If we can’t get a list of required fields for a request in the API docs, can we get a response saying, “hey this is why your request didn’t work.”

Did you use the help page to validate?


This really depends on the security posture of the API.

The OpenAPI/Swagger page should be enough to tell consumers how to use the service.

However, oversharing error information is the first thing a pen tester is going to do. If they can identify the language or framework, they have an easier time trying to break into the API.


That’s not to say that good error message should be avoided, it just means they shouldn’t be exposed to the caller but instead placed in a logging area that only the developer has access.

1 Like

If you are getting this message it generally means it isn’t even close to what its looking for it can’t tell you what you have wrong because what you sent it it can’t make heads or tails of.

Are you using the SWAGGER helper page? What are you trying todo? Unable to deserialize is such a fundamental problem (before you even get into the Epicor logic) that it would be really hard to diagnose. It is simply telling you it has no idea what you are giving it.

1 Like

Here in the lies the thing.

I’ve had a couple calls now. Where I missed one of the required fields. All I get back from the API is: “Unable to deserialize entry”

I figure out what field it wants, add it and all is well.

I’ve worked with APIs from Google, Amazon, Digital Ocean, Rackspace, Mailchimp, Hubspot, Paypal/Braintree, Other payment systems, Monday.com, Teamwork, Mailgun, Sengrid, and plenty more. If I missed a field, pretty much every single API from listed companies would tell me that. Or at least say, Hey, you are missing a required field. Maybe it wouldn’t name the field, but at least I know what is going on.

If the argument is because of pen testing… I’m already authenticated. It’s like worrying about a burglar after they are already in your kitchen.

Or a concern about having access to this data to allow pen testers to break into the API… I would hope that giving information like, what fields are required in a request or having incorrect data types, wouldn’t make that possible. It’s really no different than a response back of 200.

This has happened a couple times to me. Different calls, different situations. And after messing with it, I figure out the fields required. It’s never been the JSON being incorrect.

I’m just asking for what I’ve seen in the past, from other massively used APIs, a normal feature. Feel like I’m asking for ketchup and mustard on a burger here at a burger joint.

I have been using SWAGGER and I think at the moment all the calls I’ve been working on have been resolved. I’m just asking for a feature. That’s all.

I do appreciate all the help from you guys in the past, I hope you don’t take any offense to any of this. I just want to make everyone’s lives easier.


The place to ask for new features is Epicor Kinetic Ideas
If you don’t have a login, you can put in a wayfinder request in EpicCare to get one.

Thank you. I’ll get on there an post the request.

1 Like

Error “Unable to deserialize entry” happens before you get to the real API, it is what ASP.NET Core tells you when it cannot understand the JSON data you sent and cannot transform it into known instances of objects… Probably you did not write quotes correctly or did not set pairs of { } or [] in right order.

1 Like

Here in lies the thing, well two things. REST and Zero Trust.

I’ve been following REST for years and have hung out with far too many RESTafarians as Bart used to call them. REST was NEVER supposed to be an RPC protocol. It was designed to scale and send requests to server farms and not rely on a connection, like HTTP itself. It is stateless, hence the name - REpresentative State Transfer. But we programmers are used to our ways and companies found it easier to provide endpoints that are RESTful but not strictly REST. Retrieve an object, add an object, update an object, or remove an object no matter which server happened to get the request and every request afterwards. This was the goal of Roy Fielding, the person behind REST. Have Google, Monday, Amazon, MailChimp, etc. adopted Roy’s vision? Maybe in certain areas, but in general, no. Our industry carries the history of the telegraph and telephone. We need a circuit, a connection, something familiar to rely on. Managing state without a connection is tough to wrap our minds around.

There are some here who have embraced the concept, like @Aaron_Moreng. Instead of using the REST endpoints for the business objects directly, they call Epicor Functions or BAQs. All the gory details of required fields, types, etc. are kept outside the client. They took FULL control of the APIs and didn’t relegate their API desires to an Ideas program. In doing so, they also encapsulated away some of the risks during Kinetic upgrades since the clients are no longer tightly coupled with Kinetic. Bonus: Epicor Functions are callable from the new Kinetic UI enabling code reuse across multiple clients.

No, it is not about pen testing. The “burglar in the kitchen” was the situation for Google with Operation Aurora when they found multiple “burglars” in their “kitchen.” Or the NSA with a burglar named Edward Snowden - who was authenticated. Just this week’s patch Tuesday features a zero interaction bug in the Windows Outlook client that allows threat actors to get AD credentials. The Kitchen door is more open than we want it to be.

These kinds of events are what is driving the adoption of Zero Trust architectures. In Zero Trust, it’s no longer good enough to be authenticated. One has to verify they have access to that resource using any and all attributes (MFA, registered and healthy client, location, etc.) that are appropriate for that resource.

Everyone assumes they’re too small to be a target to do the extra work to handle security properly. But this posture makes us soft enough to get to our customers. Applied Materials lost an estimated $250,000,000 in sales last year due to a breach in one of their “smaller” suppliers. That’s a legal headache I would rather not have.

I, too, hope you all don’t take any offense to any of my blabber. I, too, want to make everyone’s lives easier.


I was hoping you’d respond. Loved the RESTafarians.

Thanks for the examples and never ceasing to help others understand just how important it is to have a good posture.

It’s one thing to dismiss the idea of Zero Trust, it’s another to pay no attention to it. Thanks for making sure we are all aware of it.

To @carguy 's post, I too wish I could know what was wrong with the rest call- coming from a novice programmer. And I also want to stay safe… Oh the joys of I.T.

You can choose to laugh, cry, or drink.

I usually choose all 3.


Could you have a “developer” api key, and that when you make rest calls with a “dev” api key it returns useful information about the exception, but if you make a call with a regular api key it doesn’t return any more details than the UI normally would? At what point does the loss of functionality make security not worth it? Could a car that was 100% safe even move?

I don’t really disagree with your main points, but it seems like once you are getting rid of even error messages that tell you what data is required for a record (business rules) and not implementation details (like a stack trace), you are getting into the territory of security through obscurity. If I made a customization that enforced a certain business rules for quotes, but only said “There is something wrong” my users would not be very pleased. An error message is supposed to provide some value to the user.

1 Like

Oh my, Yes! Absolutely! That is in fact how writing APIs in ASP.NET works. When you put the environment in TEST or DEV, then the error messages are sent to you. This is because the entire test is happening on your machine. Yes, development is different there than the way we usually do things in ERP-Land.

That is why I am a big fan of having Dev environments for Kinetic and not working directly in production. Having the ability to stage, test, and promote those changes in an organized manner is so important.


BTW, to get full error messages in your development environment, follow Olga’s advice here:

I just wouldn’t do it with any app server connected to a database with production data.

Which is why there should be cloud dev enivornments that Epicor could spin up for cloud people (even containers some day)… :thinking:

Or even a button to refresh the pilot data… I wish I was in charge of that. Sometimes its nice to have a record from “before a certain transaction happened” and sometimes its nice to have real fresh data.

I’ve always wanted a right-mouse click “Export Object” that copies everything related to that object, including dependencies, to be imported into a dev environment. These environments could be refreshed locally very quickly. This “example” data could be stored and used later to test future upgrades in unit/integration tests.


1 Like