inklet SDK v0.1: from your data to the wall

The pencil sketch above began as our way of saying v0.1 was coming. It is here now. But the useful part is not that there is a package on npm. It is that a developer can now take something their software already knows, decide how much control to keep, and carry it all the way to a frame an inklet display confirms in the room.

That complete path is what v0.1 releases: source material, intent, routing, layout, rendering, delivery, and confirmation, exposed through one server-side TypeScript SDK. You can use it from a cron job, a backend route, a webhook, or a worker. The screen can become the quiet last step of a workflow you already have.

Picture one useful thing

Imagine a small script that runs every weekday at eight. It already knows today's three priorities, one number the team should watch, and the link behind that number. Today, the output might end up in a log, an inbox, or another dashboard someone has to remember to open. With the SDK, that same output can become a daily brief waiting on the right desk when the day begins.

The input does not have to begin as a polished screen. It can be a sentence from your database, a link to a report, a chart your job just rendered, or a PDF another system produced. Build those pieces as Assets, add one sentence describing what matters, and let inklet turn them into something made for a glance instead of another session.

npm install @inklethq/sdk

import { Inklet } from "@inklethq/sdk";

const inklet = new Inklet({ pat: process.env.INKLET_PAT! });

const result = await inklet.push.auto({
  idempotencyKey: "daily-brief-" + new Date().toISOString().slice(0, 10),
  title: "Daily brief",
  intent: "Lead with today's priorities; keep the metric secondary",
  assets: [
    inklet.assets.text("Ship onboarding, review the pilot, call Sam."),
    inklet.assets.text("Weekly activation is up 12%."),
    inklet.assets.link("https://example.com/report"),
  ],
});

console.log(result.contentId, result.state);

Choose the part you want to own

For the daily brief, Auto is the shortest path. You provide the material and the intent; inklet chooses compatible displays and builds the layout. It works when the information matters more than the exact room or typography—team updates, a changing reading list, a report that should find the people who need it.

Manual is for the moment when place is part of the meaning. Send a dinner plan to the kitchen, a visitor note to the front desk, or a project status to the display beside the team working on it. You choose the Display; inklet still reads, summarizes, and lays out what you send.

Hardcode is for the cases where your software already made the picture. A custom renderer, generative artwork, a carefully dithered dashboard, or a status board can send one finished PNG or JPEG to one Display. inklet handles delivery and panel scaling without changing the composition. Hardcode works on Free and Pro; Auto and Manual use inklet AI and require Pro.

Bring the information. Choose the room if it matters. Choose every pixel if that matters more.

The whole path is now visible

A call to push is the beginning of the physical journey, not the end of an HTTP request. The text, links, images, and files you send are Assets. Together with your intent, they become Content: the durable job inklet can fetch, summarize, route, and process. When that work is ready, the Content points to one or more Presentations—one rendered frame for each Display it should reach.

From there, a Presentation moves from preparing to queued, then published when the Display asks for work, and finally confirmed when the panel reports that it is showing the frame. That last state closes a gap most software integrations leave open: your application can know the difference between 'the API accepted it,' 'the image exists,' and 'it is actually on the wall.'

Build around what happens next

The initial push normally returns while the Content is still processing. That makes the SDK fit naturally into real background work: save the returned Content ID, let your job continue, and check the lifecycle when your product needs to show progress or react to failure. Once the Content is ready, read its Presentation IDs to see where Auto routed it or to inspect each finished frame.

A Display wakes on its own sync interval, so physical confirmation may arrive minutes after rendering. Your integration can read the next sync time, show a useful status, retry safely with the same idempotency key, or alert only when something truly fails. Re-running the daily brief with the same date-based key replays the same push instead of creating a duplicate.

What you can make with it

A company can turn a scheduled query into a morning metric that appears without opening a dashboard. A household app can place tonight's plan in the kitchen and tomorrow's departures by the door. A personal tool can pull one idea out of a notes archive each day. A home-automation workflow can render its own compact status image and send it exactly as designed.

These are different stories, but the integration is the same shape: take a signal from software, turn it into a quiet visual object, put it where it becomes useful, and keep enough state to know whether it arrived. The SDK does not prescribe the source. It gives the last mile a stable vocabulary and a complete lifecycle.

v0.1 ships with typed ESM and CommonJS builds for Node.js 20 and newer. Asset builders validate inputs locally, binary uploads retry failed tickets once, PAT authentication stays in trusted server environments, and distinct error classes preserve the details an integration needs to decide what is safe to retry. Those mechanics are there to support the story, not become the story.

The loop is closed

This is what feels new to us about the release. v0.1 is not only a way to send a request toward a display. It is a complete main path from something your software knows to something a person can notice in the right place: source, intent, layout, render, delivery, confirmation.

Start with one useful thing your application already produces. Create a PAT in Portal, install the package, and give that thing a place in the room. The guides cover the first push, all three control levels, and every state between accepted and actually on the wall.