What is the Difference Between an API and an SDK? Kristopher Sandoval June 2, 2016 Last updated: August 6, 2023 Understanding the difference between an API (Application Programming Interface) and an SDK (Software Development Kit), and knowing when to provide each, is incredibly important for fostering a developer ecosystem. In the modern development landscape, these two tools and the synchronicity between them are the driving force behind web communication and the implementation of third-party APIs. Accordingly, it helps to know what exactly we mean when we talk about APIs and SDKs. In this piece, we will attempt to create an inclusive definition of both concepts. We will give an example of each, explain how they interact with one another, and find how an API provider can effectively implement one or both of these tools to improve their offering and end developer usability. Define: API An API is simply an interface that allows software to interact with other software. This is part of its name — API, Application Programming Interface — and is core to its functionality. Think of an API as a Rosetta stone, a tablet by which two vastly different languages, two different instruction sets, can be translated and transferred for mutual understanding. APIs come in many shapes and sizes. The browser that a reader would likely use to peruse the Nordic APIs website uses a variety of API sets in order to convert user commands into usable functions, request data from servers, render that data into a viewable format for the user, and validate the performance of their requests. Even something as simple as copying and pasting on a computer utilizes an API. Copying text converts a keystroke into a command, data is stored into RAM on the clipboard utilizing an API, the data is then carried from one application to another using that same API, and finally, data is rendered when pasting using yet another API. On the world wide web, the API takes on a slightly different function. Web APIs allow for interaction between disparate systems, often for specific use cases. For instance, when a user interacts on Twitter, they’re utilizing an API to comment, to store their data, to follow a user, to delete tweets, and so forth. Ultimately, a web API is simply a set of instructions, just like the personal computer API, but based in the web space. Perhaps most important is the fact that APIs allow for consistency. In the early years of programming, the computer was a wild west of commands and instructions, loosely coded and rarely documented. With the advent of modern computing, APIs have allowed for consistent coding in stable environments, allowing for replicable functions to be delivered the same every time the request is submitted with reliability and predictability. Still unsure on API business strategy? See our free eBook on Developing the API Mindset Define: SDK SDK stands for “Software Development Kit”, which is a great way to think about it — a kit. Think about putting together a model car or plane. When constructing this model, a whole kit of items is needed, including the kit pieces themselves, the tools needed to put them together, assembly instructions, and so forth. An SDK or devkit functions in much the same way, providing a set of tools, libraries, relevant documentation, code samples, processes, and or guides that allow developers to create software applications on a specific platform. If an API is a set of building blocks that allow for the creation of something, an SDK is a full-fledged workshop, facilitating creation far outside the scopes of what an API would allow. SDKs are the origination sources for almost every program a modern user would interact with. From the web browser you work on all the way to the video games you play at the end of the day, many were first built with an SDK, even before an API was used to communicate with other applications. Squares and Rectangles Part of the confusion behind the difference between APIs and SDKs is the fact that, more often than not, an SDK contains an API. In geometry, “rectangles” is inclusive of both rectangles and squares, whereas “squares” is inclusive only of squares. The same is true with APIs and SDKs. By definition, an SDK is a kit that includes instructions that allow developers to create systems and develop applications. APIs, on the other hand, are purpose-built for an express use — to allow communication between applications. It should be no surprise then that, when an SDK is used to create an application that has to communicate to other applications, it includes an API for this functionality. Inversely, an API is used for communication, but cannot be used solely to create a brand new application. Another way to understand this is to think in terms of houses. APIs are telephone lines, allowing for communication in and out of the house. The SDK is the house itself and all of its contents. Examples Luckily, we have a great example of the difference between an API and an SDK in the Facebook suite of solutions. Because this suite provides tools for both active users and developers, it includes both an API and an SDK, each with different functionalities and use cases. Facebook APIs Used internally and with third-party application providers, the Facebook API allows for communication across the wide Facebook social platform, and utilizes the social connections and profile information data points of every Facebook user to conduct application functions. These functions include pushing activity to “news feeds” and “profiles” on the main Facebook site but also include third party application functions such as registering for external sites and subscribing to media outlets. Page, photo, event, friend, and group data is collected and collated and used to form meaningful and useful connections that increase the extensibility of the service. The API also allows for the limiting of this data sharing on a per-user basis, allowing for users to limit their profile content and the use thereof. This integrated security allows for extensive use of multiple data points and resources while still maintaining high privacy and security levels. The functionality of this API extends beyond internal usage, however. One of the greatest strengths of the API is the tie-in to the Graph API Explorer. This service allows for the observation of relational data between users, photos, accounts, feeds, and more. This sort of analytic generation is incredibly powerful — as we’ve previously stated, metrics is one of the most powerful assets an API provider can have. GET graph.facebook.com /me? fields=albums.limit(5){name, photos.limit(2){name, picture, tags.limit(2)}},posts.limit(5) Here we see a sample API issuance. In this call, the API is used to request a user’s photo, the URL the photo generates, and all the people tagged in the photo. While this is a rather simple use, consider the possibilities — a restaurant manager or even host could use this API call to generate a list of users in a photo shoot at a specific engagement, generating a list of social accounts they can reach out to for further publicity or promotion. Try doing that without the API! Graph API isn’t the only API in town, either. Facebook also provides the Marketing API, designed specifically to allow brands to craft engaging and effective social campaigns for their products. This API not only shows how powerful the Facebook platform is, but how powerful properly structured API design can be. Because the Marketing API primarily drives advertising campaigns, the structural design reflects this purpose and is laid out in such a way as to inspire proper campaign design as a secondary benefit. The benefit of this structure can be seen in how the Marketing API deals with optimized effective CPM. CPM, or “cost per mille”, is a concept wherein actions are given a value and interaction is given a cost. These costs can be best optimized by the advertiser to prioritize marketing goals and deliver ads in the most effective and efficient way possible. use FacebookAds\Object\AdSet; use FacebookAds\Object\Fields\AdSetFields; use FacebookAds\Object\Values\BillingEvents; use FacebookAds\Object\Values\OptimizationGoals; $adset = new AdSet(null, 'act_'); $adset->setData(array( AdSetFields::NAME => 'My Ad Set for oCPM', AdSetFields::BILLING_EVENT => BillingEvents::IMPRESSIONS, AdSetFields::OPTIMIZATION_GOAL => OptimizationGoals::LINK_CLICKS, AdSetFields::BID_AMOUNT => 150, AdSetFields::CAMPAIGN_ID => , AdSetFields::DAILY_BUDGET => 1000, AdSetFields::TARGETING => array( 'geo_locations' => array( 'countries' => array( 'US' ), ), ), )); $adset->create(array( AdSet::STATUS_PARAM_NAME => AdSet::STATUS_PAUSED, )); In this example, the Marketing API has created a campaign that can be bid upon under constraints set up by the campaign budget values. This dynamic bidding makes for a very powerfully optimized system that captures the highest-value impressions and establishes a value that makes sure the ROI ratio of input to expense isn’t exceeded. A dynamic bidding system allows for the best return on the dollar — this is the power of a properly crafted API, allowing for complex interactions and manipulations above and beyond what any portal or internal page could deliver on its own. Read more here: The Power of Advertising APIs to Create Targeted Social Campaigns Facebook SDKs We can see the main difference between SDKs and APIs in their expressed functions. While the previously mentioned APIs are clearly designed for interaction between applications and campaigns or other applications, the SDKs provided by Facebook are clearly designed for the creation of these applications. Let’s look at the Facebook SDK for iOS. Designed specifically to allow for the development of Facebook applications for iOS, the SDK is fully featured, allowing for a multitude of functions to be defined and called. As a basic example, the following code snippet is from the SDK reference guide for iOS: // AppDelegate.m #import <FBSDKCoreKit/FBSDKCoreKit.h> - (void)applicationDidBecomeActive:(UIApplication *)application { [FBSDKAppEvents activateApp]; } This example allows for the logging of application activations and is thus one of the more basic possible examples to provide. Nonetheless, one can see the difference between an API and SDK in the basic structure of the calls. While the API calls existent sources and functions to perform an action already defined, the SDK is used to first define this function and to create a way to call the source and function. The Android SDK is much the same but translated into the language of the Android OS. Further changes can be seen in the Web SDKs, such as the JavaScript SDK, which utilizes JavaScript to perform the same basic function building as the iOS and Android SDKs. The SDK is the building blocks of the application, whereas the API is the language of its requests. This is an apt description, “building blocks”, which is made abundantly obvious when one looks at what an SDK contains. Libraries from which to build functionality, code samples for increased understanding and easier implementation, and references for easy linking and explanations — without any of these, an application or service might be functional, but it certainly would be severely hampered. Of key interest is the fact that our analogy still holds — the API references existing functions and calls, while the SDK calls the API. See this following example code from the SDK reference guide: FB.ui({ method: 'share_open_graph', action_type: 'og.likes', action_properties: JSON.stringify({ object:'https://developers.facebook.com/docs/', }) }, function(response){ // Debug response (optional) console.log(response); }); This code creates a share dialog that pops up over the application page when an action is performed and publishes an Open Graph action which can then be tied into the greater ecosystem and used to generate complex relationships and metric data. Related: How Many Languages Should Your Helper Libraries Support? Other API and SDK Comparisons If we look beyond Facebook developer services, we’ll find examples of web APIs and SDKs in a variety of other contexts. Often, an API-as-a-product will provide a RESTful API so that any type of client, regardless of implementation, can make a call over HTTP to the API. Then, the services will provide an ancillary SDK to make it easier for an engineer to make an integration while developing with a specific programming language or platform. For example, Mux is a platform that makes it easier for developers to insert video experiences into their applications. To integrate Mux video infrastructure, you can program directly against the Mux API at the endpoint https://api.mux.com. For example, here is a curl call to the Video API which creates a new Mux Video asset: curl https://api.mux.com/video/v1/assets \ -X POST \ -d '{ "input": "https://muxed.s3.amazonaws.com/leds.mp4", "playback_policy": ["public"] }' \ -H "Content-Type: application/json" \ -u ${MUX_TOKEN_ID}:${MUX_TOKEN_SECRET} Or, developers can use Mux SDKs, like mux-node-sdk, mux-python, and mux-elixir, which support the Node.js, Python, and Elixir programming languages. These help developers generate the necessary code using more native functions in each programming language. SDKs and helper libraries are often supported by the company, as in the case with these official Mux wrappers. At other times, however, they are maintained by the community. Apples and Oranges Realistically, the comparison between API and SDK is often confusing only because of how far they overlap — a problem only complicated with the addition of new methodologies for organization and segmentation, such as Docker containers, which require their own specific API and SDK documentations. To simplify the concept, remember the following: SDKs usually contain APIs; no APIs contain SDKs. SDKs allow for the creation of applications, as a foundation allows for the creation of a house; APIs allow for the functioning of applications within the SDKs defined parameters, like the phone lines of a house. With this basic understanding and a few key code examples, the difference between SDKs and APIs should now be obvious. The latest API insights straight to your inbox