Did API v1 of Erp.BO.PartSvc/Parts Change Over the Weekend?

Kinetic ERP
21

Hey! How about a bug report so I can figure it out? :wink:

22

Yeah, think you’ll have to stick it out with support until they get a dev (like @Olga or @bconner ) to look at it. Sorry :frowning:

23

They said last night they’ll be writing up a PRB for development to look at. It’s super easy to replicate - just hit the Erp.BO.PartSvc/Part OData endpoint with a part# that contains a slash. My real curiosity is if this is isolated to us, or if it affects everyone. We’re on 12.1.100.10.

24

I am surprised if it ever worked. / Usually indicates part of the path in the URL

25

You can see in his screenshots its being escaped as %2F so I wonder if that is really the root of the issue.

26

So I think its a setup issue on your side… or maybe that ole Linux thing. It works fine for me in 2025.2.12 (12.1.100.12) (on windows)

image
image1527×756 71.9 KB

Anyone know what Epicor is using to host on linux is it Kestrel? or are they reverse proxying through NGinX

27

Interesting! Thank you for testing this, Jose. I’m going to update one of our dev instances to .12 and see if this is still happening there.

28

Worked on my pilot, which is Linux / 17-hotfix-d / 2025.2.10

image
image1492×995 18.4 KB

29

That’s not the same call I’m making. You’re calling GetByID. Try calling Erp.BO.PartSvc/Part(companyID, partNum). v1 or v2 doesn’t seem to matter.

30

Oh, my bad. Yes the OData does give an error:

image
image1490×661 14.5 KB

image
image1862×398 35.2 KB

31

I’m on the same version in windows… I’m getting more and more suspecious of Linux

Can one of you post your RESPOSE headers from the calls. See if we can determine if Linux is being run through KESTREL or via reverse proxy?

32 
 cache-control: no-cache,no-store 
 connection: keep-alive 
 content-type: text/plain 
 date: Fri,20 Feb 2026 15:29:17 GMT 
 expires: -1 
 pragma: no-cache 
 server: nginx 
 transfer-encoding: chunked
33

Ah they are reverse proxying in NGINX… I have one of those… Stand by

34

OK!!! Now we’re getting somewhere. Thanks Evan!

@josecgomez there was an nginx update over this past weekend. What I don’t understand is how a web host update could foul up an API signature, unless the transfer from the proxy is somehow corrupting the data?

35

Well the NGINX proxy may not be properly handling URL encoding. Here’s what might be happening:

When a client sends a request with special characters (like spaces, parentheses, etc.) in the URL, those characters should be URL-encoded (%20 for space, %28 for “(”, etc.). The reverse proxy has to decide whether to:

  1. Pass the encoded URL as-is to the backend (Epicor)
  2. Decode and re-encode the URL before forwarding
  3. Normalize/sanitize the URL in some way

If NGINX is decoding the URL and then passing it to Epicor without proper re-encoding, or if it’s applying different encoding rules than what Epicor expects, you could end up with mismatches. This is especially problematic with characters that have special meaning in URLs or URIs.

There are specific NGINX directives that control this behavior:

  • proxy_pass with/without trailing slashes behaves differently
  • URL rewrite rules can inadvertently decode/re-encode
  • The $request_uri vs $uri variables handle encoding differently

I have an NGINX proxy in front of my Epicor environment - I’m gonna test this there and see if there’s a specific config directive that needs to be adjusted to preserve the exact encoding that Epicor expects.

36

When I try it in my live (windows) I get a different error:

image
image1461×778 18.1 KB

37

This makes sense, thank you!

38

It works on WSL and Kestrel

image
image816×492 11.7 KB

39

What about NGINX Proxy? I’m trying to teest it but I forgot mine runs through IIS. I’m setting up a new test.

40

i don’t have it :woman_shrugging: