@RAIJMONDL

You cannot fetch the DX “service rule” object itself at runtime, because the engine hides the dispatcher, but you can read the incoming HTTP context and use that in your logic. Grab the request info from pxRequestor.pxHTTPServletRequest, especially pyRequestURI or pyPathInfo to know which DX endpoint was called, pyMethod for GET or POST, and pyQueryString if you need parameters. Read headers from pxRequestor.pxHTTPServletRequest.pyHeaders() to detect DX specifics like the DX API version and content type. If you need the payload, look at pyRequestBody on the parameter or service page created for the call, which the activity or data transform can parse. Wrap this into a reusable data page or data transform that sets flags like IsDX, DxVersion, Endpoint, and CaseID from the URI and headers. Use those flags anywhere in your rules instead of trying to resolve the service rule. If the same logic must also work for Portal clicks or job schedulers, guard it by checking whether pxRequestor.pxHTTPServletRequest exists before reading it. For auditing, you can also log pxServicePackage and pxServiceActivity when the call enters your service activity, if those properties are present on the step or parameter page in your service context