feat!: rebuild the SDK from the API's OpenAPI document

[AminChirazi]

The published package has sat at v0.2.0 since February 2024 while the API moved on for two and a half years. It exposes four methods - generate, generateFromTemplateId, exportToApi, exportToDB - and none of projects, scenarios, sets, keymaps, plans or masking. That is less a coverage gap than a misrepresentation of the product to anyone who finds it.

The fix is structural, not a catch-up

The cause was hand-copied types: nothing ever failed when the API and the SDK diverged. Adding the missing methods by hand would fix today and guarantee the same drift reopens.

So src/generated/schema.ts is generated from spec/openapi.json - the document datamaker-api now emits and commits (automators-com/datamaker#2879) - and CI fails when the committed types no longer match. Drift becomes a build error instead of a discovery.

const dm = new DataMaker({ apiKey: process.env.DATAMAKER_API_KEY });

await dm.sets.save({ name: "golden customers", data: rows });
const { mappings, missing } = await dm.keymaps.lookup({
  mapName: "sap-material-migration",
  object: "Material",
  oldKeys: ["OLD-1", "OLD-2"],
});

Client	Methods
dm.projects	list get create update delete
dm.templates	list get create update delete
dm.sets	list get create update delete save
dm.keymaps	list put lookup entries delete
dm.maskingPolicies	list get create update delete
dm.plans	list get update delete

Method names mirror datamaker-py, and apiKey/baseURL fall back to DATAMAKER_API_KEY / DATAMAKER_API_URL - the same variables Python reads - so one configured machine works with both.

Deliberate choices

• Zero runtime dependencies, on the platform fetch. Runs unmodified on Node 18+, Deno, Bun, browsers and edge runtimes. We considered a shared Rust core for both SDKs and rejected it: an SDK is URL building and JSON, there is no shared logic to justify FFI, and native binaries would cost exactly the environments customers deploy to.
• DataMakerError carries status and parsed body, not a flattened string. 401 means the key is wrong, 403 that it is right and lacks a permission, 409 that the resource is locked - callers branch on that.
• A non-JSON error body still reports its status. A proxy timeout answers HTML; the status is the useful part and must not be replaced by a parse error.
• sets.get returns SetDetail, which the spec composes as Set & { createdByName }, so that field is not silently assumed to exist on list results.
• KeyMap methods return projections, because the API has no endpoint that returns a stored KeyMap row and the SDK should not invent one.

Tests

11 tests, none of which touch a real API: they inject a fetch stub and assert on the request the SDK builds, which is this layer's entire job. The old suite required DATAMAKER_API_KEY in CI, so it passed or failed depending on the environment.

CI now runs generate:check → lint → test → build, all green locally.

Breaking

v0.2's four methods are removed. Replacements live on the typed resource clients, and anything not yet wrapped is reachable through the typed dm.http transport. Changeset included as a major.

Follow-ups

• connections is intentionally absent: it is blocked on the plaintext connectionString question raised in automators-com/datamaker#2882.
• 30 of 239 API operations currently have typed responses; the rest return unknown until their routes are annotated. Adding them widens the SDK's types automatically.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.