DigitalOcean publishes its OpenAPI spec at digitalocean/openapi — the same description behind their public API v2 docs. You can generate a typed client from it. DigitalOcean's own official SDK coverage is narrower than most vendors in this series — Go (godo) and Python (pydo) — so a generated client fills a real gap for TypeScript, Ruby, or any other language.
Where the spec lives
| Fact | Value |
|---|---|
| Repo | digitalocean/openapi |
| Source | specification/ (split across resources/ and shared/, $ref-linked) |
| Bundled download | api-engineering.nyc3.digitaloceanspaces.com/spec-ci/DigitalOcean-public.v2.yaml |
| Spec version | OpenAPI 3.0.0, info.version: '2.0' |
| Size | ~3.07 MB (bundled YAML) |
| License | Apache-2.0 |
| Status | README states "currently in Early Availability" |
How to fetch it
DigitalOcean's repo README is explicit that the bundle is generated on every merge to main and published to DigitalOcean Spaces — that's the file to use, not a raw path inside the repo:
curl -sL -o digitalocean-openapi.yaml \
https://api-engineering.nyc3.digitaloceanspaces.com/spec-ci/DigitalOcean-public.v2.yaml
If you want the source instead (useful if you're filtering by resource before generating), clone the repo and bundle it yourself with the Makefile target DigitalOcean ships:
gh repo clone digitalocean/openapi
cd openapi && make bundle
The honest complication: the spec is explicitly unstable, and the source isn't one file
Two things worth knowing before you build anything long-lived on this spec:
It's labeled Early Availability. DigitalOcean's own README says so directly: "the specification should be accurate, [but] it is under active development. The structure of this repository may continue to evolve." That's a stronger caveat than most vendor specs in this series carry — treat generated code from it as something to regenerate regularly, not vendor once and forget.
The source is split, not bundled. The repo's specification/ directory holds a top-level DigitalOcean-public.v2.yaml alongside separate resources/ and shared/ directories, linked by $ref. Confirmed by listing the directory:
curl -s https://api.github.com/repos/digitalocean/openapi/contents/specification \
| grep '"name"'
# DigitalOcean-public.v2.yaml, description.yml, inference_description.yml, resources, shared
That means the checked-in root YAML isn't necessarily self-contained — DigitalOcean's own build runs make bundle to resolve everything into the single file published at the Spaces URL above. Point your generator at the published bundle, not a raw file path inside specification/, unless you've run the bundle step yourself.
Generate a TypeScript client locally
npx @openapitools/openapi-generator-cli generate \
-i digitalocean-openapi.yaml \
-g typescript-fetch \
-o ./generated/digitalocean-client
For types only:
npx openapi-typescript digitalocean-openapi.yaml -o ./src/digitalocean-api.d.ts
Given the Early Availability status, run the bundle through the free OpenAPI validator each time before generating — it's the fastest way to catch a structural change before it breaks your build.
The hosted path
Sourced takes the published DigitalOcean bundle directly — paste the Spaces URL or connect your repo — and produces hosted docs, a TypeScript SDK preview, a Python SDK preview, and an llms.txt file in one pass. Because the source spec changes as DigitalOcean iterates on it, regenerating a preview is a re-paste rather than a local rebuild. Previews are free and unlimited, with up to two hosted noindex docs sites and one hosted MCP server, no credit card required.
When this actually makes sense
- A language DigitalOcean doesn't officially cover. Their official SDK list is Go and Python — TypeScript, Ruby, and most other ecosystems have no first-party client at all.
- Prototyping against a fast-moving spec. Early Availability means the spec itself is a reasonable way to explore what's coming before DigitalOcean ships a first-party client for your language.
- Internal wrappers around
doctl-adjacent tooling that want typed request/response shapes without adoptinggodoorpydo's specific patterns. - Agent tooling. A generated client, or an MCP server built from the spec, gives an LLM agent typed tool calls against DigitalOcean's API.
If you're writing a Go or Python app that manages DigitalOcean infrastructure, use godo or pydo — they're official, maintained, and track the API's actual behavior more closely than a generated client from a spec still labeled Early Availability.
FAQ
Does DigitalOcean have an official OpenAPI spec?
Yes. digitalocean/openapi is DigitalOcean's own repository, described in the README as "the OpenAPI v3 specification for DigitalOcean's public API v2," currently labeled Early Availability.
Where's the actual file to download?
Not a raw path in the repo — DigitalOcean publishes a bundled version on every merge to main at api-engineering.nyc3.digitaloceanspaces.com/spec-ci/DigitalOcean-public.v2.yaml, linked directly from the README's "Spec Download" badge.
What does "Early Availability" mean for this spec?
DigitalOcean's own words: accurate but under active development, with the repository structure expected to keep evolving. Treat it as something to re-fetch and regenerate against regularly rather than a stable artifact to pin indefinitely.
Is the DigitalOcean OpenAPI spec OpenAPI 3.0 or 3.1?
3.0.0.
Should I generate a client instead of using godo or pydo?
Not for Go or Python — those are official and maintained by DigitalOcean. Generate a client for TypeScript, Ruby, or any other language DigitalOcean doesn't officially cover, or for agent tooling.
Can Sourced track the spec as DigitalOcean updates it?
Yes — since the source changes as the spec evolves, Sourced regenerates docs and SDK previews from a fresh paste of the bundle URL rather than requiring a pinned local copy. Previews are free and unlimited.