Bsrgvty

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.

Good answers already, I just thought of a different approach which may or may not work for you.

Rather than issuing keys to be included you could require the header of requests to include the name of the front end application, to be created and formatted by the developer of the front end application, like web browsers do. That way front ends could still pretend to be a different application but there would be no benefit to doing that so that seems unlikely. Just let the front end identify itself and accept any non-empty string.

In short:

First: facilitation and benefits; If necessary: friction and police.

Some more words

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...

Generally the easiest way to get developers to "do the right thing", is to make it easy for them to do so.

To that end I would suggest building a API key issuing web page/site.
In its simplest form it could be just a login (ideally tied to your corporate AD/LDAP) and the page that just asks for the application name and issues the key.

At the end of the day you can always revoke keys later, so all you really need the site to do is record who (username) requested the key and what (Application Name) they want to do with it - along with any info needed to revoke the key later.

You could do something similar with a ticketing system, but at the end of the day it's very easy for me to copy and paste a key from one app to another, so it has to be really easy to request a new key, to avoid bad behavior.

Be pro-active.

Identify likely developers and GIVE them unique API keys in a secure channel, ahead of time. Provide an easy means of requesting new API keys. Provide an easy means of new people requesting new API keys. When new interns or hires join the team, give them a JIRA ticket or similar "Request an API key" with the steps in the description.

Keep track of which API keys have been used, and which ones haven't. If Bob has submitted tickets in the project but hasn't been using his API keys, then he's probably borrowed someone else's.

Have Management's Support. Don't be a Nosy Nancy going any making up rules that don't matter. Literally convince Management that it's important, and then they are the ones to convince the group that it's important. Don't work on convincing everyone.

And the most annoying and tyranny-prone suggestion :
Be aware of misuse, and crack down on the same day. Same hour is best. Don't say "Bad Naughty Developer" say "Here are the proper steps." If they do it repeatedly, disable the misused key. This hassles both the Sharer and the One Who Borrowed, and the sharer will say "No, do it properly" in the future. Avoid disabling keys that are in live projects.

How can we incentivise developers not to share API keys internally?

• Generate keys as a result of self-service application registration.


• 
  Require a point of contact before keys become active.


• And ask them not to share. (Create a terms of service and/or tell them why it's better for them not to share.)

You should also implement rate-limiting. This in itself could discourage sharing of keys. It protects your system to some extent against abusive applications. (And downright malicious ones.) And, it ensures you'll be somewhat informed prior to a massive increase in serviceable traffic. (Giving you time to add capacity, I hope!)

And, with rate limiting, when an application does require a higher limit, it opens dialog with the POC registered for the key. You get an opportunity to ask if keys are being shared, explain why that's harmful and so forth, and you can offer additional keys when it's appropriate instead of the requested rate limit changes. Etc.

One way to do things, especially if the teams use a shared build system (or at least a sufficiently common one) is to set up an internal server that creates and issues API keys (given a few basic bits of info about the product using it). Then use a script that grabs a new API key from the server for each build, or for each version update. Let devs run the script to get a different key for their local builds as well. (Where possible, automate this as part of the build so they don't even need to think about it.)

This would let you tell whether it was something in production, QA, or dev, and at what version/build the problems started.

The first and best thing you can do is to format the keys so that they include the application name in an easily readable form, and don't work if you change it.

If it's obvious when teams are using the wrong key, then they'll endeavor not to.

Then, periodically expire keys. You should do this anyway, and when a key is nearing expiration you can send a new one to the team that owns it. The team that uses a key will then be motivated to ensure that they are the team that owns it, so that they'll get the new one when it expires.