Official American Cloud SDKs for TypeScript, Go, and Python

You can now talk to American Cloud from your own code with a typed, official SDK — in TypeScript, Go, or Python. Each one is a single install away on the registry you already use:

npm install @americancloud/sdk

pip install americancloud

go get github.com/American-Cloud/americancloud-sdk-go@latest

Here's the whole loop in TypeScript — authenticate, list your VMs, done:

import { AmericancloudApiClient } from "@americancloud/sdk";
 
const client = new AmericancloudApiClient({
  apiKey: process.env.AMERICANCLOUD_API_CLIENT_ID!,
  apiClientSecret: process.env.AMERICANCLOUD_API_CLIENT_SECRET!,
});
 
const vms = await client.vms.listVms();
console.log(vms);

The client is namespaced by resource — client.vms, client.blockStorage, client.kubernetes, client.dnsZones, and so on. The Go and Python clients mirror the same shape, idiomatically: client.Vms.ListVms(...) in Go, client.vms.list_vms() in Python (with an async variant). Every method, parameter, and response is fully typed, so your editor autocompletes the API and your compiler catches a typo before it ships.

All three are generated from our public OpenAPI specification with Fern, which is why they stay consistent across languages and in step with the API.

The version is the contract

Here is the part worth slowing down for, because it's unusual.

The SDK version is the API version. SDK 1.3.0 — in every language — is generated from version 1.3.0 of the American Cloud API surface. There is no compatibility matrix to consult, no "SDK 4.2 works with API 1.7" table to keep in your head. If you want to know which API revision an SDK release targets, the version number is the answer.

Most SDKs version independently of the API they wrap. The client library marches to its own release cadence, the service evolves on another, and reconciling the two becomes a research project every time something breaks. We collapsed that into one number on purpose. The pin in your lockfile — "@americancloud/sdk": "1.3.0", americancloud==1.3.0, @v1.3.0 — states exactly which API contract your code was written against. You can read the changelog for that version and know precisely what you're getting.

The boundary that actually matters for breakage is the API URL version, /api/v1. Breaking changes — removing a field, changing a type, making an optional parameter required — only ever ship under a new URL version like /api/v2. They never land silently inside /api/v1. So a pinned 1.x SDK keeps working as long as v1 is live, and v1 stays available for at least six months after a v2 ships. Additive changes — new endpoints, new optional fields, new enum values — arrive within a version, so write code that tolerates a field or enum value it hasn't seen before. Upgrade when you choose to, not because a dependency drifted underneath you.

This matters because the SDKs are generated from a contract we've been deliberately hardening. The 1.3.0 release is a good example: firewall and ACL rule ports are now integers on the way in, matching the integers the API had always returned on the way out — no more string-on-write, number-on-read seam for a typed client to choke on. And object storage's maxBuckets is now a number or null (where null honestly means "no limit"), instead of the magic string "unlimited" masquerading as a number. Small things, but they're exactly the inconsistencies that turn a typed client into a pile of special cases. We wrote up the full story of how a strict client forces an API to tell the truth in Terraform made our API better — that's the deep dive; this is the payoff.

Published the way you'd want them published

In 2026, the supply chain is the threat model. A package you install runs with your privileges, on your machine, in your CI. So we publish these the careful way.

The TypeScript and Python SDKs use Trusted Publishing (OIDC) on npm and PyPI. There is no long-lived publish token sitting in a CI secret waiting to be stolen — the registry verifies a short-lived, workflow-scoped identity at publish time and grants it permission to upload only that package. There's no credential to leak because there's no credential. On top of that, the public-repo npm releases carry provenance attestations: cryptographic proof, recorded publicly, that the package you install was built from the public source in our GitHub repository and not tampered with in between. The Go SDK needs none of this middle layer — Go modules are consumed straight from the public repository by import path, so what you go get is what's in the repo.

You don't have to take our word for any of it. The SDKs are open on GitHub, the spec they're generated from is public, and the provenance is verifiable.

One spec, every surface

These SDKs aren't a side project — they're one face of the same contract. The same OpenAPI specification drives the API reference, generates these three SDKs, and backs our MCP server for AI assistants. Whether the thing driving American Cloud is a TypeScript service, a Go CLI, a Python script, or an AI agent in your editor, it's talking to the same hardened surface. If you'd rather your AI assistant do the driving, start with the MCP server.

Get started

1. Create an API key — read-only or read-write — at console.americancloud.com/api-keys. The client secret is shown once, so store it somewhere safe.

2. Install for your language:

   sh[ copy ]

   npm install @americancloud/sdk
   pip install americancloud
   go get github.com/American-Cloud/americancloud-sdk-go@latest

3. Follow the quickstart for TypeScript, Go, or Python — or start at the SDK overview.

Found a rough edge or want coverage we don't have yet? Each SDK is open source — open an issue on GitHub. And our Terraform provider is live on the registry, built on the same spec — through the Go SDK, in fact.