What is an SDK?

If an API is the socket a service exposes, the SDK is the toolbox shipped alongside it: the official package — code libraries, documentation, examples, utilities — that a platform hands developers so they can build on it quickly and correctly. The examples touch business projects directly: mobile apps are built with Apple's and Google's SDKs; payment flows arrive as processor SDKs that bundle ready-made card forms, validation and 3-D Secure rather than leaving developers to assemble raw API calls; login with Google, maps, push notifications and analytics all snap in the same way. The classic confusion is the API relationship: the API is the communication contract (what you can ask a service), the SDK its comfortable implementation in a given language — an API can be used without one, but the official kit saves time and mistakes, which is why "do they offer an SDK for our stack?" quietly decides what an integration costs. The angle buyers rarely hear: every third-party SDK mounted in your app is foreign code running with your app's permissions. Analytics and advertising kits have historically been the channel through which otherwise honest apps leaked user data — with the privacy liability landing on the app's owner, meaning you — and outdated kits carry known vulnerabilities. Two legitimate acceptance questions follow: which third-party SDKs does our app contain, with a reason for each; and who keeps them current, since platforms update constantly and app stores eventually reject antique versions.