As the title says, has anyone been successful connecting 2026.100 to QuickShip and freighting a Customer Shipment or Misc Shipment?
I have the REST API integration setup with QuickShip, and carriers FedEx and UPS are setup using the test account data provided in the QuickShip setup guide.
I can freight a Misc Shipment directly in QuickShip, but I can’t seem to do anything except Rate Shop in Customer Shipment Entry or Misc Shipment Entry. It’s like Kinetic doesn’t have the correct endpoint or something - as soon as a click the Freight icon, I get an immediate Business Layer Exception with no additional error info. When I look up the correlation ID, I see this:
System.Net.Http.HttpRequestException: Response status code does not indicate success: 404 (Not Found)
Currently working with support, but based on the methodology they’re using to try and determine the issue, I don’t hold out much hope for getting anywhere.
Could be irrelevant but we’ve got a PRB open on Customer Shipment Entry. It now opens with records from ALL of our sites…and allowed user access to update a pack from a site that their profile does not have access to.
No problem…for your issue it could be something, could be nothing…but there’s definitely something amiss here. It’s a breach of user security, that’s for sure.
Just got off a call with QuickShip support. There are changes in QS 2026 and Kinetic that I haven’t found documented, so I’ll put them here to hopefully ease someone else’s pain:
In Company Configuration > Modules > Materials > Shipping & Receiving, if you’re using the REST API integration, the the API URL is: https://[your-quickship-server]/, not https://[your-quickship-server]/dist?registrationcode=[your-code]
I’m waiting for guidance on this, but the QuickShip user I had configured in QuickShip to communicate with Kinetic and has ISC_Admin permissions, refused to connect to the endpoint. I had to change this to use the admin user, which I hate because I don’t control it, but it’s what worked. I’m waiting to see if this is a new requirement.
As a bonus, I learned that you can set an App Setting so that when you log into QuickShip, it doesn’t take the license away from a workstation. Add the key SuperAdminUserName, set the Value field to the user you want to have this, and enter any description and Save. Now when you log in to troubleshoot, you aren’t taking a workstation license away.
I’ll follow up on the username issue once I get an answer.
Yes, you can enter any valid QuickShip username. I don’t use the default admin account, so I added my username to the value setting for SuperAdminUserName in Setup > Application Settings.
Edit: if you’re asking about item#2 in my post, that was resolved in the .6 release. You do not have to use the admin account.
I’ll piggy back on this since we’re in a QuickShip predicament. We are currently unable to ship via QuickShip, but we’re likely in a unique situation - cloud Kinetic, but on prem QuickShip. Don’t ask, I inherited this.
Anyway - when we freight, we get an error that hits the server log as
[System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at ``http://quickshipweb/EpicorFreightService.svc?regCode=XXXXXX`` that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
Epicor / QuickShip Support was surprised this config worked in the first place, but now that we’re on 2026.1, we’re dead in the water. DevTools in the browser shows a request in the Network tab going to http://quickshipweb/EpicorFreightService.svc?regCode=XXXXXX - this url works fine by itself in the browser but isn’t reachable via Kinetic.
I tried giving the QS site it’s own port and changed the workstation to point to the IP:port (http://10.X.X.X:YYYY/EpicorFreightService.svc?regCode=XXXXXX) but that didn’t work either.
Support says we need to migrate to QuickShip in the cloud, but I’m hesitant to accept that since they were surprised our previous config worked. More time and more $$$. I can’t help to think that there’s a small config change to make this work.
Any ideas?
Update: in 2025 using the smart client, the request to quickship was made locally - so internal addresses were addressable. Both of our tests yesterday were to local addresses (https://quickshipweb/ and https://10.X.X.X:YYYY) - I changed Workstation to point to a publicly addressable page on my personal webhost, tested the freighting and logged the request. It hit just as expected - so I think we just need to expose our on-prem QuickShip to Epicor cloud.
