REST Services V2

Hi Everyone

has anyone used REST services V2?
I am trying to execute REST services from POSTMAN/.NET using the api-key but it doesn’t work HOWEVER if I use the same URL in a web browser it works.

if use REST services v1 with basic authentication, I can use them by using POSTMAN, Web Browser and .NET

this is an example of my URL

thanks for your help

There are a few questions that have been asked about V2 in the forum already. Please check that out

I can’t speak to POSTMAN, but Excel’s ODATA driver is incompatible with V2 as it interprets the API Key differently from the way Epicor uses it. Epicor tells you to disable the need for the API key in the config file, but if you are on SaaS , they will not edit the config file for you so you are out of luck.

Not sure if your symptom is related

after try several time and research on internet, I just arrived to the conclusion that I still need to use the Basic Authentication and api-key for REST V2.
Using POSTMAN, try to use the same structure as my URL, you will get the following

401 - Unauthorized: Access is denied due to invalid credentials.

then go to Authentication and add your user and password and you will be able to get the result

now, if you remove the api-key from the URL


you will receive the following error

{“message”:“Access denied: Rest calls must pass a valid API Key”}

so, my conclusion is … REST V2 needs both authentications

the funny thing is that if you execute the following structure in your browser, it works


in addition, this is the code for .NET that I am using, if you have a more elegant way to do it, please let me know

var defaultRequetHeaders = HttpClient.DefaultRequestHeaders; defaultRequetHeaders.Authorization = new AuthenticationHeaderValue(“Basic”, authUserPwd); HttpResponseMessage response = await HttpClient.GetAsync(webApiUrl);


1 Like

@erzt23 You’re correct Rest v2 requires both an authorized login and an api key. Currently api keys do not map to user accounts though we may add a second api key type that does that in the future for service <-> service integrations.


Yea currently the API key isn’t really a security mechanism. More of a way to limit the scope of what objects a client can get access to once you have the credentials.

Not to be picky, but there’s authentication and authorization and both are required for security. First I need to know who you are (authentication) then I can control what you do (authorization). You really need both for security. The API-KEY improves the authorization over what is available prior to 10.2.400. Mapping API-KEYS to users or user groups would definitely give even finer control to authorization.

1 Like

Team, I am having issues with V2. I can get data with the V1 URL, but not with V2. I get a 500 - Internal Server Error.

What’s on the EventViewer (server side)?

Bummer. That, I do not have access to at this point. They will stick with V1 until we get this resolved, so it isn’t an urgent thing at this point.