Both SDKs are generated from the same OpenAPI spec that powers this reference. Method names, parameters, and response types match the spec exactly. When the API changes additively, the next SDK release picks up the new fields without you touching anything.
Published SDK packages will land at @pivotal/api (npm) and pivotal (PyPI). Until then, generate locally with fern generate --group local-sdks against this repo. The hand-rolled snippets below show the shape — install steps are coming with the first published release.
Once published:
Highlights:
async iterator on every list* method handles cursor pagination for you. for await walks the full set.operationId.fetch for retries, tracing, or test mocks.Once published:
Highlights:
list() yields rows, walks the cursor under the hood.httpx under the hood with sane timeouts and connection pooling.pivotal.AsyncPivotalApi with the same surface.The OpenAPI spec is the contract. Generate a client in your language of choice from:
Recommended generators:
oapi-codegenopenapi-generator with ruby targetnswag or openapi-generatorprogenitor or openapi-generatorIf you generate against the spec yourself, the names of request bodies and response shapes match the operationIds — createCustomer, listOnboardings, etc. — so cross-referencing this site stays straightforward.
SDK versions follow semver:
1.0.x) — generator updates, bug fixes.1.x.0) — new endpoints, new optional fields, new enum values. Always backwards-compatible.x.0.0) — only when the underlying API ships a v2.Pin to a major version in production. Renovate / Dependabot can safely auto-bump minors.
If the SDK behaves differently than this reference says it should, that’s a bug in the generator config. Email help@pivotal.app with the SDK version (pivotal.__version__ / PivotalApi.VERSION), the method you called, and the response you got.