Thank you for your response.
So using policy I have it set to use rule 1 "TCP address does not match in datagroup at request time" then
Rule 2 HTTP URI path starts with /api at request time
Actions reset traffic.
So what the devleoper wants is to force people not in that datagroup to go somewhere else for a different API entry point(for whatever reason). However the systems or apps(webui) still need to access that /api directory path. So if I go to systemname.mycompany.com/api, not being in the datagrop it blocks the login portal to me as expected/desired, BUT the ip addresses in the datagroup that should be accessing it for app level API calls to the /api directory path are being blocked also. So the /api and the app(webui) are on the same server. So im stumped on traffic flow, maybe network level ideas as well. my logic is that if external users not in the list get blocked, good. The "internal" side shouldnt be leaving to get to layer 3 ip routing if its on the same server? i was wondering if some how it was getting in some NAT loop or something...
Ive tried so many different variations of this logic in the policy and its the same result. Thanks for your help!