I saw an old thread similar to this, but the solutions all talked about spoofing DNIS. The downside of that is that there is an extra (invisible) maintenance relationship that can be avoided if I am able to transfer directly to IAt profiles...which are able to be transfer targets and of course can be hit quite easily by a user via the client or Supervisor. So, I want my handler to do the same. Looking at the logs, I see that the Client is able to do it because it already has the ?path name?...like $(ATTENDANT)\00004NG...and it passes that to the System_TransferCallRequest handler (which, of course, can't be invoked directly even if I had the path in hand), but it's a start. I looked around for a way to dereference the path from the profile name, but have found nothing yet. Naturally, the risk of going too deep and figuring out how to mine that info out of DS or somewhere is dangerous due to a change blowing us up in the future with no warning/release notes due to exploiting an undocumented interface. So I was hoping to find some official way of making this happen or at least getting the path-y looking name of a profile from the human-friendly name. Thanks

I have a 2.4 handler that I believe is similar to what you're after, but it's a custom one from our VAR so I can't just hand it over. It's a bit too far out of my grasp at the moment, but it calls on a couple of stock 2.4 handlers that you may want to study. IntAttGetProfileKeyPath and IntAttProcessProfile are both involved.