There was another post on here about Odata breaking following the change to Linux. Epicor has a NGINX config wrong. May be causing your issues.
Just throwing my hat in the ring - this change messed up our HubSpot API integration. Devs figured out the new path, but how are we just changing method signatures all willy-nilly? Is there no one in charge?!?!
Sounds like another issue for the mega thread of Linux issues.
Mine’s a stupid Field Security thing.
So I was able to fix our apps with changing the URI to this:
https://idcspring-live.epicorsaas.com/server/api/v1/BaqSvc/{BAQNAME}(CompanyNumber)
All of my API calls are working again.
Think that’s what @GabeFranco was talking about too. The URLs changed at some point.
The whole structure changed. We went from
https://centralusdtapp07.epicorsaas.com
to
https://idcspring-live.epicorsaas.com
Some notice of this would have been nice…
Didn’t realize it was more than just the .../server/ part. Ooft. That must be what broke Azure AD for people then when the whole URL changed.
Our hasn’t even in Pilot. Yet??? ![]()
Maybe we’re sitting on a time-
here.
Neither has ours. But no better place to test other than in production…
Both should still work.
Yeah it is. So on .14 I need to get ready to change that in azure?
Not 100% sure since we aren’t cloud. But, there were some posts about needing to update your Azure SSO due to URL changes from Epicor. Let me see if I can find them. Azure is also case sensitive. So the URL configured in Azure has to match exactly what Epicor is using.
I know where to find them, thanks. Just I see conflicting statements above that “both” the old and new should work.
I think that was in terms of like integrations. For SSO only the new work.
Ohhhh I see. Okay
@pheim The original url is an unfamiliar syntax to me (our education environment uses similar syntax). We’ve had our cloud environments for about 2.5 years and always had the newer format. Still on windows hosts but watching this very closely. Thanks to everyone sharing the issues.