Before I venture down the rabbit hole, I was hoping someone could tell me if the hole has an end.
Would it be possible to send an email with 2 links, one that “approves” and one that “rejects” something in Epicor and when one is selected it sends a REST action?
Forgive me if my terminology is poor. I only have an idea of what I am talking about.
You might be able to embed JavaScript code inside your html in your email, and the JavaScript would call the endpoint
Sure, but how will you authenticate? Allow the auth login box to popup?
@Chris_Conn, clearly you didn’t catch from the tone of my question that I clearly have no idea what I am talking about 
I like shameless plugs
If it’s with JavaScript you could encode the auth inside the bpm when creating email, I think…
Here you go.
This can be done with Microsoft Flow and their Gateway.On-premises data gateway - Power Automate | Microsoft Learn
If you aren’t on O365, it can be done with Azure Functions, AWS Lambda or Google Functions and a VPN back to your private network.
We used Bezl.io to do this I have been blown away with how useful it is. I found that once you have a web based UI that can read and write from multiple different services that you suddenly don’t have to sync data between all of the services.
Of course this is hitting the SQL Database directly, so it’s not available to Cloud users and you’re bypassing the Extra Epicor Security like Territory, tenancy, company, etc.
Mark W.
Hi John,
I think I would write a web-app that would send the user to a page, authenticate if necessary, and then display the result of the action. You can of course pass in the accept or reject in those URLs. The advantage of keeping it in a web app is you’re hiding the details of the REST implementation from any changes that Epicor makes. Encapsulate that logic. If someday you move to a different ERP package, you just have to change that WebApp and you’re back in business.
Mark W.
You would actually be using REST with or without the gateway
How would you use REST without a Gateway? A publicly facing app server?
Yes - you would configure it just like MT or dedicated tenant is done today. You would need a CA signed cert (assumes externally available DNS) and firewall rules enabling the service to be exposed at the simplest level. You could use intrusion detection with some IP blacklist checks to further secure.
Yep. But of course, as a cloud user, we already have that. 
But for an on-prem scenario, you’d be doing the same. Your web service would be in the cloud (or in a DMZ) and then you restrict the REST calls to only come from that web service - much like the gateway.
Mark W.
This is what we did with a load balancer to route traffic via an ip whitelist to either the development or production environments
Ahh, on John’s link, it only showed Gateways to databases. We’ve had spotty success with the Custom API. We have E3 licenses so there’s a limit per user of one custom API per user. So maybe setting up the Gateway with REST and point it to our Dedicated Tenancy would work. Thanks @danbedwards!
So, if you were to create this on premise gateway, what type of security is required? Since it is presumably within the network, can you leave it pretty open?
Yes - The gateway is only accessible by a connector specified in your FLOW. No one else can create a connector to point to your internal gateway. Let me know if that makes sense or I can attach a couple examples.
No, that makes sense. Thanks.