The SDK client

Everything in the SDK starts with a Microtica client. You construct it once with a credential, then reach into its namespaces.

Construct a client

import { Microtica } from "@microtica/sdk";

const microtica = new Microtica({
  token: process.env.MICROTICA_TOKEN!,
});

The constructor takes one options object:

A Microtica instance exposes one namespace per resource area — projects, envs, apps, pipelines, components, git, and whoami — plus the lower-level client.

Credentials

The SDK authenticates with a Microtica API key — the long-lived mic_… credential you create in the console. A token that isn't a valid API key is rejected by the constructor, so you fail fast instead of sending an invalid credential.

The key is sent on a dedicated X-Microtica-Api-Key header; the SDK handles that for you.

Identity

Inspect the stored key through the whoami namespace.

whoami.identity() reads the key locally — no API call. The key is opaque, so it returns the key prefix and via: "apikey":

const id = microtica.whoami.identity();
// { via: "apikey", apiKeyPrefix: "mic_d60bea1d", raw: { kind: "apikey", … } }

whoami.verify() makes one API call to confirm the key works and returns the number of projects in view:

const { ok, projectCount } = await microtica.whoami.verify();

Handle errors

Namespace methods return the response data directly and throw on failure. API errors are Axios errors that carry the HTTP response, so read error.response:

try {
  await microtica.envs.get("Missing-env", projectId);
} catch (err: any) {
  if (err.response) {
    console.error(err.response.status, err.response.data?.message);
  } else {
    throw err; // network or client-side error
  }
}

Some SDK methods also throw plain validation errors before any request — for example, an app scaling change where the CPU request would exceed the limit. Those carry a kind: "validation" property.

Drop down to the raw API

Each namespace covers the common operations. When you need an endpoint that isn't wrapped yet, reach the underlying typed sub-APIs through microtica.client:

// The generated, typed clients for each Microtica service
microtica.client.engine;        // ms-engine (environments, resources, components)
microtica.client.kube;          // ms-kube (apps)
microtica.client.ap;            // ms-ap (pipelines, git)
microtica.client.project;       // ms-project (projects)
microtica.client.elasticsearch; // ms-elasticsearch (deployment history)
microtica.client.user;          // ms-usermanagement

These are the same clients the namespaces call internally, so you keep one credential and one configured HTTP layer.

Next steps

• List projects
• Manage environments
• Stream logs