Chrt SDKs

Use a Chrt SDK with an explicit API environment and supported credentials. Pin a version appropriate to your integration and validate the endpoints you use; package installation does not establish compatibility or permission.

Choose the package

The SDK families documented here are TypeScript, Swift and Java. The current web application uses @chrt-inc/typescript-sdk; confirm published package coordinates and versions with the relevant SDK repository/release before adding them to a new integration. Do not assume identical version numbers establish identical endpoint coverage.

The path of an SDK call.

TypeScript

npm install @chrt-inc/typescript-sdk

The following illustrates client construction. Supply an access token through your supported authentication flow and configure the intended API URL explicitly. Keep credentials out of browser-visible configuration and logs.

import { ChrtClient } from "@chrt-inc/typescript-sdk";
export function makeChrtClient(apiUrl: string, accessToken: string) {
  if (!apiUrl) throw new Error("An explicit API environment is required");
  if (!accessToken) throw new Error("Authentication is required");
  return new ChrtClient({
    environment: apiUrl,
    token: () => accessToken,
  });
}

Acquire/refresh credentials through your integration’s supported authentication method. The sign-in helper inside Chrt’s own web application is not a reusable public credential flow. Do not silently fall back to Development when configuration is absent.

This construction example is not an executed endpoint test. Consult the API reference for the selected environment, required authorization, request fields and response schema. A successful authenticated request must still be checked for the intended organization and resource.

Swift and Java

Use the official SDK package/repository appropriate to your runtime. Select and pin a published version deliberately. Check the release’s supported endpoints, environment configuration, authentication and platform requirements before integrating. Existing app dependency versions are evidence of that app’s setup, not a promise that every customer integration should use the same version.

Errors, retries and uploads

Read the selected SDK version’s documented error and retry options. Handle authentication failures explicitly. Do not assume every mutation is safe to retry, every upload is replayable or that a client-side success proves the intended saved result. Use idempotency where the endpoint supports it and read back consequential changes.

For support, provide the SDK version, environment, endpoint, request reference and sanitized error. Never include tokens or private payloads. Contact support for credential and integration setup questions.

Contributing

While we value open-source contributions to these SDKs, the libraries are generated programmatically. Additions made directly would have to be moved over to our generation code, otherwise they would be overwritten upon the next generated release. Feel free to open a PR as a proof of concept, but know that we will not be able to merge it as-is. We suggest opening an issue first to discuss with us!