Pull a prompt into your app
in one call.

The package is published as @cueno/sdkwith no runtime dependencies - it's a thin, typed wrapper over global fetch.

npm install @cueno/sdk

Construct the client once with your API key and reuse it. The most common path is render- it resolves the version deployed to your key's environment, validates your variables server-side, and returns the interpolated string.

import { Cueno } from "@cueno/sdk";

const cueno = new Cueno({
  apiKey: process.env.CUENO_API_KEY!, // cueno_live_… or cueno_test_…
  // baseUrl defaults to https://cueno.dev; set http://localhost:3000 for local dev
});

// the key's env picks the live version - the server renders it
const { prompt } = await cueno.prompts.render("welcome-support", {
  company: "Acme",
  customer: "Lee",
});

const reply = await model.run(prompt);

Every request authenticates with a Cueno API key, sent automatically as a bearer token. Keys are minted in the web app under Settings → API keys; the full secret is shown once at creation.

• The key's environment is authoritative. There is no envparameter - a key only ever resolves what's deployed to its environment. To read a different environment, use a key minted for it.
• Keys are workspace-scoped. A slug in another workspace returns 404, not 403.

All prompt operations hang off cueno.prompts. Every method returns a typed response (the exported types mirror the server contract) and sets Authorization and Content-Type for you.

render accepts a Record<string, string | number | boolean>. Unknown keys are ignored; a declared-but-optional variable left out is rendered verbatim as its {{token}} rather than blanked.

Any non-2xx response throws a CuenoApiError. Branch on code (stable), not message (human text that may change). For a failed render, the issues getter exposes the per-variable reasons.

import { CuenoApiError } from "@cueno/sdk";

try {
  await cueno.prompts.render("welcome-support", { company: 123 });
} catch (e) {
  if (e instanceof CuenoApiError) {
    e.code;    // "validation_failed" - branch on this
    e.status;  // 422
    e.issues;  // [{ variable: "company", message: "Expected a string value." }]
  }
}

The constructor takes a single options object: new Cueno(options).

That's the whole SDK surface. Prefer to skip the client and call the endpoints yourself? See the REST API below - every method maps one-to-one onto /api/v1.

The SDK is a thin wrapper - every method maps one-to-one onto an HTTP endpoint under /api/v1. If you're not on JavaScript, or just prefer raw fetch/curl, call the API directly. Same bearer auth, same environment semantics, and the same error envelope.

It's JSON in, JSON out. Authenticate with your key on every request; the v1 path segment is the contract version.

Authorization: Bearer cueno_live_8Kd2_xxxxxxxxxxxx

Endpoints

Resolve a prompt

The main read path - resolve a slug to the body deployed in your key's environment:

curl https://cueno.dev/api/v1/prompts/welcome-support \
  -H "Authorization: Bearer $CUENO_API_KEY"

{
  "slug": "welcome-support",
  "title": "Welcome Support",
  "description": "Opening line for support chats.",
  "environment": "production",
  "version": { "label": "v3", "author": "kit", "createdAt": "2026-05-28T00:00:00.000Z" },
  "body": "You are {{agent_name}} for {{company}}. Greet {{customer}}.",
  "variables": [
    { "name": "company", "type": "string", "required": true, "note": null }
  ]
}

Render with variables

POST the values and let the server validate and interpolate. An empty body (or no variables) is treated as {}; unknown keys are ignored, and an optional token left unprovided stays verbatim.

curl https://cueno.dev/api/v1/prompts/welcome-support/render \
  -H "Authorization: Bearer $CUENO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "variables": { "company": "Acme", "customer": "Lee", "agent_name": "Ada" } }'

{
  "slug": "welcome-support",
  "environment": "production",
  "version": "v3",
  "prompt": "You are Ada for Acme. Greet Lee."
}