It's not necessarily that API consumers feel they must be blessed, it's that it's less hassle. And less likely to land them in a courtroom for for violating AP

It's not necessarily that API consumers feel they must be blessed, it's that it's less hassle. And less likely to land them in a courtroom for for violating API terms of service. "Stealing" someone else's API key sounds like a great way to prove intent to do so - not good! Baked-in client keys still have some non-security uses: The ability to control rate limiting and help trace bugs/performance issues back to their original "well behaved" clients. It also adds some minor friction for badly behaved ones (more so if everyone's obfuscating it in their clients.) EDIT: Some API docs request that you self-report about your client in e.g. your User-Agent string for similar reasons, when no "blessing" is desired. Server-side keys don't actually magically solve any problems anyways. You're just shifting the problem from "how does Twitter prevent API abuse by unauthorized clients" to "how do I prevent API abuse by unauthorized clients". You may be in a better position to solve that problem post-shift (e.g. "I'm okay with unofficial clients - but authorized user must individually auth against their paid account!) but you might not ("I just wrote my own twitter client - I'm in no better position to prevent API abuse than twitter.") > That said, it isn't 100% clear to me that if someone released a true Twitter client Apple would remove it The way I see it working is Twitter's lawyers sue the author of the unauthorized user of their APIs for intentional ToS violations & circumventing protections (where all those wonderful anti-hacking laws come into play) when they ignore the cease and desist - and either nip the problem at the source when they show up to court, or get a default judgement and a court order they can deliver to Apple. It's a meatspace solution instead of a digital one, but it works.