About the SDK

Dime.Scheduler ships official SDKs in four languages, plus a command-line tool. All of them live in the dime-scheduler/sdk monorepo, all are generated from the same OpenAPI specification, and all expose the same surface - only the casing and idioms change.

Language	Package	Status
.NET	Dime.Scheduler on NuGet	Stable
JavaScript / TypeScript	@dimescheduler/sdk on npm	Stable
Python	dimescheduler on PyPI	Alpha
Rust	dimescheduler on crates.io	Alpha
Go	Ships as the dimescheduler CLI via Homebrew, Scoop or direct download	Stable

The dimescheduler CLI is written in Go against the same OpenAPI specification, so its commands stay in lockstep with the SDKs. The Go client package behind it is not published as a standalone module yet; if you work in Go, script the CLI or call the REST API directly.

Environments

Every SDK and the CLI target production by default and let you pick another environment at construction time. There are two:

Environment	Base URL
Production	https://api.dimescheduler.com
Sandbox	https://sandbox.api.dimescheduler.com

Each has its own API key portal: production and sandbox. A key only works in the environment it was created in.

Shape

Every SDK exposes a single DimeSchedulerClient constructed with an API keyAPI keyA credential that authenticates calls to the Dime.Scheduler API. The preferred way to integrate over the deprecated JWT flow. and (optionally) an environment. Each entity hangs off a typed accessor:

// JavaScript / TypeScript
const client = new DimeSchedulerClient({ apiKey: "MY_API_KEY" });
await client.categories.create({ name: "VIP", displayName: "VIP", color: "#22d3ee" });

// .NET
var client = new DimeSchedulerClient("MY_API_KEY");
await client.Categories.CreateAsync(new Category { Name = "VIP", DisplayName = "VIP", Color = "#22d3ee" });

# Python
client = DimeSchedulerClient(api_key="MY_API_KEY")
client.categories.create({"name": "VIP", "displayName": "VIP", "color": "#22d3ee"})

// Rust
let client = DimeSchedulerClient::new("MY_API_KEY");
client.categories.create(&Category { name: "VIP".into(), display_name: "VIP".into(), color: "#22d3ee".into() }).await?;

There are three kinds of accessor:

• CRUD entities - about thirty of them - expose create / update / delete / getAll on a generic accessor. Both single entities and batches work.
• CRUD with a read on top - jobs, tasks, appointments, time entries and time sessions add a get for a single record or a date range.
• Specialized endpoints (geocodingGeocodingConverting an address into map coordinates so a job or resource can be placed on the map and used for routing., optimization, recommendationRecommendationA ranked suggestion of resources for a job, matched on skills, location and availability. Available through the API and through the MCP server’s recommendation tool., notifications, messages, task assignments, …) get their own methods. A few entities are read-only (calendars, resource types, appointment fields, appointment dependencies) and only expose getAll.

Pick a language and follow the install, usage, and examples pages on the left. If you already know one SDK, the others read the same way: the accessor names are kept in lockstep across all of them.

When to use the SDK vs the CLI vs raw HTTP

• SDK - embedding in an application (web app, integration service, scheduled worker). You get typed entities, per-language ergonomics, and automatic retries on 429 and 5xx in every SDK except Rust, which leaves retrying to you.
• CLI - scripts, CI jobs, one-off batch loads. Same accessor model, but you script it from a shell.
• Raw HTTP - when neither fits, or you're working in a language without an official SDK. The API is documented in the reference.

A recipe uses this page

• Populate a fresh instance from codeEnd-to-end quickstart: insert resources, filter groups and values, indicators, jobs and tasks - and wire up the assignments between them.