Migrating to SDK v1.0
The v1.0 release of the Vitable Connect SDKs is a new generation of our client libraries, rebuilt on a new SDK pipeline. The REST API itself is unchanged — same endpoints, same request and response shapes on the wire, same authentication — but the generated client code has a new internal architecture, so upgrading from a 0.x SDK requires some code changes.
Package names are unchanged on every registry, so the upgrade is a normal version bump:
Every endpoint page in the API Reference shows install and usage snippets generated directly from the v1 SDKs. When in doubt about exact syntax for a specific call, the reference is the source of truth.
What stays the same
- Authentication. The client still reads your API key from the
VITABLE_CONNECT_API_KEYenvironment variable by default, and still accepts it explicitly via the same constructor option (apiKey/api_key:). - Python and Ruby entry points.
from vitable_connect import VitableConnectandVitableConnect::Client.new(...)work as before, and Python’s async client is stillAsyncVitableConnect. - Resource layout. Calls are still grouped by resource
(
client.auth,client.employees,client.employers, …), with the same method names in Python and Ruby. - Typed responses. Responses remain fully typed objects in every language.
What changed
TypeScript
The two changes most likely to touch your code are the client import and property casing.
Client import and construction. The package’s default export has been replaced with a named client class:
Property casing is now camelCase. In 0.x, request parameters and response fields mirrored the wire format’s snake_case. In 1.x they are idiomatic camelCase, converted to and from the wire format for you:
Pagination is still an async-iterable page — for await loops carry over
with at most a casing change on the item fields:
Errors. The per-status error classes (BadRequestError,
AuthenticationError, RateLimitError, …) are replaced by a single error
hierarchy rooted at VitableConnectError, which carries the HTTP status code
and the response body. Branch on statusCode instead of the class:
Retries and timeouts are configured per request rather than only on the client. Every method accepts a final options argument:
Python
Python is close to a drop-in upgrade: imports, client class names, method names, and snake_case parameters are unchanged.
The changes to review:
-
Errors. The per-status classes are replaced by a single
ApiErrorbase carryingstatus_codeandbody. Replaceexcept NotFoundError:style handlers with a branch on the status code: -
Pagination still iterates transparently across pages:
-
Retries and timeouts can now also be set per request via
request_options, in addition to client-wide configuration.
Ruby
The client entry point and method calls are unchanged:
The changes to review:
-
Pagination.
auto_paging_eachis replaced by standard iteration — list calls return an enumerable that fetches subsequent pages automatically: -
Errors. The
VitableConnect::Errors::*per-status classes are replaced by a single API error rooted in theVitableConnectmodule carrying the HTTP status code and response body. Rescue the base error and branch on the status code.
Staying on 0.x
The 0.x packages remain on the registries and keep working against the API, but they no longer receive updates — new endpoints and fields will only appear in 1.x. If you are not ready to migrate, pin your dependency to your current 0.x version and plan the upgrade.
Questions
If you hit a migration issue not covered here, contact your Vitable integration engineer or email dev@vitablehealth.com.

