We’re working on a new service - this service will potentially be called directly from applications on user devices. These applications will be developed and supported by multiple development teams from all over the organisation, all depending on the data we provide.
We’re keen to identify which applications are sending which requests, so that we can identify usage patterns and developers responsible. (For the avoidance of doubt, user authentication is handled separately.)
Our solution is to require API keys, per application - then we have contact details for the development team.
We don’t want getting the API keys to be a source of friction, but we’re concerned that developers will share them to colleagues in other teams, meaning we can no longer identify traffic for just one application.
How can we incentivise developers not to share API keys internally?
In order to share those keys between teams, the teams need to talk to each other, agree to share, then share them. This takes time. So if a team can request API keys from you more quickly and more easily, there's no incentive to share.
And the easiest way for them to request those keys is for you to pre-empt them. Assuming you know all the other teams that will need API keys, create them and share them before making the service available to them.
There's one other incentive that you can offer: debugging support. Those teams will want your help when things don't quite work properly when they integrate their work with your service. Those API keys allow you to track their specific requests and thus to assist in debugging what's going wrong. So sell that as the reason for the keys, rather than "identify usage patterns and developers responsible", which sounds like you are spying on their activities.
Facilitation, benefits, friction and police:
Facilitation: First, make it easy for a team to get a new API key. For instance add a reminder in the corporate procedures for launching new projects, and offer an easy to use service to request a new keys, without asking for justification.
Benefits: Make the usage of an own API key be a benefit for the team or the product owner. For example, propose some feedback about app usage based on that key.
Friction: Depending on the key feature, you can create friction, for example if key is linked to somme app-defined domain (i.e. reusing keys would not necessarily give access to all desired services).
Policing: Finally, you may need to foresee some policing measures. For example, you may monitor usage of api functions by api key and after a given time to establish a baseline, inquiry about use of api parts which is not expected in view of the baseline. Or if this is not realistic, simply include in the corporate project-review checklists the verification that a valid key was used.
*Remark: you may need to be very clear on your API key policy: Would a new major version require its own API key ? What with a fork, or if an app is split up ? what if another team is in charge, etc...