Platform SDK

A platform SDK is one of the four SDK types described in the encyclopedia subject area Software development kits, alongside developer, publishing and hardware SDKs; the type is treated in detail under platform SDKs. Unlike a software development kit that mainly wraps a remote API, a platform SDK is defined by the host: the host decides which extension points exist, when extension code is activated, and what it is allowed to touch.

The pattern is visible across very different hosts. In Visual Studio Code, extensions combine static declarations in the contributes field of the package.json extension manifest with calls into the JavaScript extension API, and the manifest identifiers must match across contributions so the editor can activate them together. In the Eclipse IDE, plug-ins are OSGi bundles that carry a manifest with OSGi headers and declare extensions and extension points in plugin.xml. Shopify app extensions are configured in a shopify.extension.toml file in the app's extensions/ directory, which names the extension, its type, API version and targets. Office add-ins declare requested permissions in their manifest and run their web page inside a host-managed, sandboxed runtime.

How it applies

• Document the extension point, not just the call. For each documented feature, name the host extension point or target, the manifest key that declares it, and the API surface the extension may use. Readers cannot infer manifest keys from API names.
• Treat the manifest as an interface contract. Manifests are usually JSON, TOML or XML; a schema or host-side validator rejects unknown or malformed keys, so schema validation errors belong in the troubleshooting section of your docs.
• Make permissions explicit. Platform SDKs generally ask extensions to declare scopes or permission levels up front; documentation should map each feature to the permission it needs and to the authorization model of the host. Declaring a permission is a technical prerequisite, not evidence that a use of data is lawful or secure.
• Plan for two version axes. An extension depends on an SDK version and on a host version range. Publish the compatibility matrix and use semantic versioning consistently; host deprecations, not your release plan, often drive breaking changes.
• Expect a review and distribution gate. Marketplace review, signing and staged rollout are part of the platform SDK experience and should appear in your release checklist alongside build and test steps.
• Interoperation with the other SDK types. A platform extension frequently calls out to a developer SDK for cloud services, embeds output produced by a publishing SDK (in-product help, release notes, embedded documentation), or surfaces data that originates from a hardware SDK. In documentation, keep the boundary explicit so readers know which SDK owns a failure and where logging or observability data is collected — host sandboxes often restrict what an extension can write or read.
• Sandbox limits shape the samples. File system access, background threads, native modules and network egress may be blocked or proxied. Samples that work in a standalone project may not work inside the host.

Platform SDK vs. Microsoft's former "Platform SDK"

The two meanings are unrelated and are a common source of confusion:

• Platform SDK as a type of SDK (this entry): a kit for extending a host application through extension points, manifests and sandboxed APIs.
• "Platform SDK" as a former Microsoft product name: the kit of headers, libraries, samples, tools and documentation for building Windows applications, released in 1999 as the successor to the earlier Windows and Win32 SDKs and later continued under the name Windows SDK. Microsoft's current downloads and documentation use "Windows SDK"; the older name survives mainly in legacy headers, build scripts and historical accounts. Published histories of the naming are largely secondary sources, so treat specific release-by-release details as uncertain unless confirmed in Microsoft's own SDK archive. By the typology used here, that kit is an operating-system and platform-target SDK, closer to a developer or hardware SDK than to an extensibility kit — which is why this glossary qualifies the term when precision matters.

In writing, resolve the ambiguity on first use: "platform SDK (extensibility kit for a host application)" or "Windows SDK (formerly Platform SDK)".

External references

• Visual Studio Code Extension API — Contribution Points
• Visual Studio Code Extension API — Extension Manifest
• Eclipse documentation — Plug-in (OSGi bundles, extensions and extension points)
• Microsoft Learn — Office Add-ins manifest
• Microsoft Learn — Privacy and security for Office Add-ins
• Shopify — Configure app extensions
• Microsoft — Windows SDK archive
• Wikipedia — Microsoft Windows SDK (history of the Platform SDK name; secondary source)

Keep in mind

This entry names vendor platforms only as examples. Product names, manifest formats, extension point catalogs, permission models and marketplace rules change between releases — Microsoft's rename of the Platform SDK to the Windows SDK is itself an example. Verify every identifier against the host vendor's current documentation for the version you target.