Getting 404 when posting to /episerverapi/commerce/import/catalog from C#



as a proof of concept I have a clean Alloy Tech CMS extended with Commerce nuget package. I have installed Service API for Commerce nuget package in the CMS part and was able to get the access token when posting to /episerverapi/token

I have followed instructions given here and I keep getting 404 when posting the to the /episerverapi/commerce/import/catalog from C# code. This happens both on localhost (http and https) and on test environment on azure.

Does anyone know if something has changed recently in URL signatures compared to the instructions?

Oct 23, 2017 13:57

No, the Url is a part of the public "API" so they can't be changed without a major release - and no we haven't changed that.

Did you try postman to do the posting? How does your request look like? Did you try with some GET APIs? 

Oct 23, 2017 16:19

Yes, I did try postman.

GET requests also return 404
for example here is the request for /episerverapi/commerce/catalogs

GET /episerverapi/commerce/catalogs HTTP/1.1
Host: localhost:44358
Authorization: bearer YjEYPG1S1IDRl-XirJAH91T-R4WWaDPq6c9-Dy10oxtKx2CN6y4UhqBC4tPuys-BLoQJ-ihTCqfaLl2nu61XInC0EQXAmpKZvE14ME5fPhIjPntPBsSHU0wBen8YN6lip1iZzUrXuL2xOwyfDYgN5t17QM2nJJhWUxGLfOktE4HD206Zk3HtuQDIHxjtRhlSRSdRUGsPV1UBWvBfdGc_OacFCCMGfADuN0NNPrwwCT69e0-1zY9u4NepVzLvyaGqZQ3i8iaieyXDa9iNBP7VII4mEUxB-B1v2UNVWH4atUhw-6F1GBM5b5xhS6IBADxEA9K3Z0Luj8u93lGCkXP8HWwONmfM6oHN_SwWat0exUQkHlHqxDJN_shM-Ie7c1ppfvq8vr90Bx6J_A4VMbHUQLIORgMOzOYgNtdziVQSTuzaBu8kfUMndSkvrYjzUAlZcLKggLGXH6EE5oBcUxqBBYNNfSFKsJzh0iHLe8Z-8kPSTJqbe0CyOlTwWXPHeHHO
Cache-Control: no-cache
Postman-Token: f3cd363a-c69b-1718-a889-246ddabcfc72

and here is the request for the /episerverapi/commerce/import/catalog

POST /episerverapi/commerce/import/catalog HTTP/1.1
Authorization: bearer pLgAViNNgOfK90_9yIP-9_dYK2uc-_uzx-SES6QicJ5ecPmCkV8kKvca82TY4gcfDg0fg_KsFp5bSA4CSvWIi4IeSd6Mxwg4VTaTFaIR6AKvgLddJTuS9jXrMF2UlTq7CWNMXnM9NNGFOoSkfceWEe1RxBDFgGg-9TW3_O0_ucg7OxucqYHPiuvl5JfSo5Zs10SrkS6nhHvQGmb6BMj76GRmj5eYSYF4ckWkuOfioJWHZVtVBtiUbXsfwruFRL8AHNo6v6E7oTRMPP08llk9bR4FaYHJPjSOPVx7zapGdCXPd5rZbULG4d-8CwQFdnX9My4LLH_0TJ3IyFtlQzHkZg8eB8nPwariOjrsbacvvGgdwzzt8uhfeaZrrSTEKJCp5gDPHaw81HYbR1MxY1uu_WT_U36HzBJjvXLfFygzAKZCyM7E7zijeIZKog5V_VHDsPE2hAPxg-YMGhSVSGf40SPzwv0prVP-VgesICN2uwrU1KkeUbiYMP5Pdo1rXBjJ
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Cache-Control: no-cache
Postman-Token: 898fb270-2e33-38d4-2ee1-7241494167a5

Content-Disposition: form-data; name=""; filename=""
Content-Type: application/x-zip-compressed


Implementation of the Configuration(IAppBuilder app) is like this

public void Configuration(IAppBuilder app)

            app.UseAdministratorRegistrationPage(() => HttpContext.Current.Request.IsLocal);

            app.UseCookieAuthentication(new CookieAuthenticationOptions
                AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
                LoginPath = new PathString(Global.LoginPath),
                Provider = new CookieAuthenticationProvider
                    OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager<ApplicationUser>, ApplicationUser>(
                        validateInterval: TimeSpan.FromMinutes(30),
                        regenerateIdentity: (manager, user) => manager.GenerateUserIdentityAsync(user))

            app.UseServiceApiIdentityTokenAuthorization<ApplicationUserManager<ApplicationUser>, ApplicationUser>();

I imagine now that something is not implemented right but what confuses me is the fact that I could get the token from the GET request to /episerverapi/token

Oct 24, 2017 9:39

Nice job Goran - this is a kind of question that I'd want to see more on World - you spent time investigating the problem, and you express it in a way that easier for us (or me at least) to understand. 

I would assume that you have this in your appSettings episerver:serviceapi:maphttpattributeroutes to false?

Oct 24, 2017 12:08


Both that setting and


are set to false.

When doing everything from the beginning I was getting YSOD in case that setting was not in place. Just now, when trying to replicate YSOD by removing that specific setting, it passed without a glitch, so I gave it another go in the Postman. This time I got a 401 error 'User is not authorized for this request'.

Moreover, when tried to implement this on the latest Quicksilver solution installed from GIT I kept getting invalid_grant event when accessing the token URL. I didn't have time to investigate more on the implementation of Quicksilver but I found out that when creating CMS admin user in vanilla implementation I can log into CMS as admin and can get a nice token using those credentials, but when creating a new CMS admin in Quicksilver (no matter if username was in a form of or just username) due to redirection to Login page I could use only username that was in a form of email address but in any case I couldn't login as admin into CMS. This causes, in my opinion, that invalid_grant response when trying to get the token with those credentials.

This is what I need to solve next after I sort out 404 in the question.

Oct 24, 2017 12:36

Unless if you are calling config.MapHttpAttributeRoutes(); yourself, then you should not set that to false. I think it returns 404 because the route attributes were not properly mapped

Oct 24, 2017 14:02

Looks like it. 401 means that the user was not authorized as I wrote in my previous answer. 

Which user group should user belong to in order to get acceptable token? If it's related to user groups at all. Both test users that I created belong to WebAdmins group.

Oct 24, 2017 15:06

Go to admin mode, Config / Permissions to Functions.  Find the Read Access and Write Access for Serviceapi and update to include WebAdmins role.

Oct 24, 2017 19:56
<p>Mark thank you. Here is an update. When following 'the path from the scratch' nuget packages add only read/write access rights to Administrators group in the table&nbsp;tblUserPermission.&nbsp;Even <a href="">here</a> it says you need to check it up in the step 9. Yet the only existing group (from scratch) that user can be placed into is WebAdmins.&nbsp;</p> <p>So besides your solution developer can&nbsp;manually create Administrators group in the admin mode and place user into that group and that solves 401.</p>
Oct 25, 2017 9:27
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.