Should a custom HTTP header or parameter be used to identify the caller context for a RESTful service?

My team inherited a WCF service that serves as a gateway to many back-end systems. The first step in each call to this service is a decision point based on a context key that identifies the caller. This decision point is essentially a factory to provide a handler based on which return system the request should be routed to.

We look at simplifying this service in a RESTful service and look at the benefits and implications of passing the context key as part of the request header rather than adding the context key as a parameter eachservice call. On the one hand, when looking at separate service implementations for each of the backend systems, the caller context appears to be orthogonal. However, using a custom header leaves me with a somewhat awkward feeling as the essential detail for the service calls is masked from the visible interface. I should point out that this is a purely internal solution that alleviates some of my concerns about the visibility of the interface, but even internally doesn't know if the next engineer will try to connect or change the service will know hidden information about it.