Previously, in order for an API provider to use Context Plugins for their API, their SDKs had to be published to a public package manager such as npm, NuGet, or PyPI. That left teams whose SDKs live behind a private host — internal APIs, partner integrations, or APIs that aren't yet ready for public distribution — without a way to offer the same AI-assisted integration experience.
We've now added self-hosted SDK support in Context Plugins. Instead of pulling the SDK from a package manager, the AI agent downloads the SDK package from your portal, installs it locally in the developer's workspace, and wires it into their project — all without the SDK ever needing to be published.
Self-hosted SDK support in Context Plugins is intended for exploring and evaluating the feature. It is not recommended for production use today.
What's New
Self-hosted SDKs work exactly like the existing Context Plugins flow once configured — same AI-assisted integration entry point, same supported IDEs (Cursor, VS Code, Claude Code), same end result. The only difference is where the SDK comes from: instead of npm install, pip install, or the equivalent for your language, the agent fetches the SDK artifact directly from the URL where you host it, installs it locally, and then writes the integration code against it.
How to Try It Out
You can try this flow end-to-end using the APIMatic CLI. Once your build file is configured (see Configuration below), generate your portal and deploy it to the host that matches the baseUrl you configured — the SDK artifacts must actually be reachable at that URL for the agent to download them:
apimatic portal generate
Then deploy the generated portal output to your hosting provider (Netlify, S3, internal server, etc.) at the absolute baseUrl you specified in the build file. Once it's live, open the deployed portal, go to the AI-Assisted Integration tab on the Getting Started page, pick a language, connect your IDE of choice, and let the agent handle the SDK download, install, and integration.
Configuration
The self-hosted SDK flow is triggered automatically when your APIMatic build file meets all of the following conditions for a given language. If any of them are missing, the portal falls back to the standard published-SDK Context Plugins flow.
The build file uses two different key formats for languages. The languageConfig block is keyed by language name (java, python, csharp, etc.), while portalSettings.languageSettings is keyed by SDK template name (java_eclipse_jre_lib, python_generic_lib, cs_net_standard_lib, etc.). Both refer to the same language — the template name selects a specific SDK flavor for that language.
1. Absolute Base URL where your artifacts are hosted
Set an absolute baseUrl either at the root of generatePortal or under portalSettings. This is the URL where your SDK artifacts will be sourced from, so make sure the server hosting that URL is reachable and serving the artifacts — the agent will fetch the SDK from there.
{
"generatePortal": {
"baseUrl": "https://your-portal-host.example.com",
"...": "..."
}
}
2. No publishing settings for that language
In the languageConfig block, the entry for the language you want to use self-hosted SDKs for must be left empty — no publishSettings or publishing info. When publishing settings are present for a language, that language is treated as a published SDK and the standard Context Plugins flow is used instead.
{
"generatePortal": {
"languageConfig": {
"java": {},
"csharp": {},
"php": {},
"python": {},
"ruby": {},
"typescript": {}
}
}
}
3. At least one AI integration enabled per language
Under generatePortal.portalSettings.languageSettings, the language must have at least one of cursor, vscode, or claudeCode enabled in its aiIntegration block.
{
"generatePortal": {
"portalSettings": {
"languageSettings": {
"python_generic_lib": {
"aiIntegration": {
"cursor": { "isEnabled": true },
"vscode": { "isEnabled": true },
"claudeCode": { "isEnabled": true }
}
}
}
}
}
}
4. A valid API Copilot key in the build file
Context Plugins are powered by API Copilot infrastructure, so a valid apiCopilotConfig.key is required.
{
"apiCopilotConfig": {
"isEnabled": true,
"key": "your-api-copilot-key"
}
}
Putting it all together
A minimal build file enabling the self-hosted SDK flow for several languages looks like this:
{
"$schema": "https://titan.apimatic.io/api/build/schema",
"buildFileVersion": "1",
"generatePortal": {
"baseUrl": "https://your-portal-host.example.com",
"languageConfig": {
"java": {},
"csharp": {},
"php": {},
"python": {},
"ruby": {},
"typescript": {}
},
"portalSettings": {
"languageSettings": {
"python_generic_lib": {
"aiIntegration": {
"cursor": { "isEnabled": true },
"vscode": { "isEnabled": true },
"claudeCode": { "isEnabled": true }
}
},
"java_eclipse_jre_lib": {
"aiIntegration": {
"cursor": { "isEnabled": true },
"vscode": { "isEnabled": true },
"claudeCode": { "isEnabled": true }
}
}
}
}
},
"apiCopilotConfig": {
"isEnabled": true,
"key": "your-api-copilot-key"
}
}
A Note on Reliability and Model Choice
The self-hosted SDK flow asks the AI agent to perform real setup work on the developer's machine — downloading, installing, and wiring the SDK into a project. Because AI agents are inherently non-deterministic, the agent may not approach the same setup the same way every time, and behavior depends on the capabilities of the underlying model.
This feature is intended for exploring and evaluating Context Plugins. It is not recommended for production use today.
To get the most consistent results, we recommend running Context Plugins with frontier-class models at higher reasoning effort levels. These models are more likely to execute the full install-and-integrate sequence end to end on their own. Smaller or lower-effort models may instead produce a setup script for the developer to run themselves rather than carrying every step out autonomously — still useful, but a different experience.
As model capabilities continue to improve, we expect this flow to become more reliable across a wider range of setups.