Designing with Sleek

Overview

sleek.design provides a REST API at /api/v1/* to create projects, design screens from a brief, and fetch their HTML and renders.

Base URL: https://sleek.design
Auth: Authorization: Bearer $SLEEK_API_KEY, except the public device start/poll endpoints
Content-Type: send application/json for JSON request bodies.
CORS: Enabled on all /api/v1/* endpoints
Envelope: check HTTP status first. Successful JSON wraps its payload in data; lists also include sibling pagination. Errors use top-level code, status and message, with optional data.url. Successful screenshots and share cards return image bytes; 204 has no body.
Ids: opaque 11-character tokens like V1StGXR8Z5j, with no type prefix. Nothing about an id says whether it names a project, screen, component, version or theme, so track each one by the response field it arrived in.
Parsing responses: write the body to a file (curl -o run.json) and parse the file. Piping JSON through echo corrupts it: zsh expands the escaped \n inside string values into real newlines, which makes the body invalid JSON.
API docs: OpenAPI spec at https://sleek.design/api/v1/spec.json; browsable docs at https://sleek.design/api/v1/docs. Fetch the spec for any contract detail not covered here.

Designing or implementing

A single run can take both directions — "design me a fitness app and build it in Expo" is a design pass followed by an implementation pass. Gate each pointer on the artefact in front of you rather than on a one-time reading of the request:

Designing — you are about to send a chat message to Sleek. Read designing.md first; it carries the create → chat → screenshot loop, how to author a style direction, and when to seed one from a reference instead.

Implementing. Before writing code from a Sleek design, read implementing.md for version selection, native conversion, working features, and acceptance checks.

User shot and review shot

Screenshots come in two framings, and each file below asks for one by name:

• A user shot is the default render: viewport height, phone-shaped. This is the one you show the user.
• A review shot adds fullHeight: true, one component per request. This is the one you judge your own work against.

Prerequisites: API Key

If SLEEK_API_KEY is not set, use the device flow so the user never handles the raw key:

1. POST https://sleek.design/api/v1/device/start (no auth) with body {"source": "your-tool-slug"}. The response contains a verificationUrl, a human-checkable userCode, a secret deviceCode, and a poll interval in seconds.
2. Show the user the verificationUrl and the userCode, and tell them to confirm the code matches before approving.
3. Poll POST https://sleek.design/api/v1/device/poll with {"deviceCode": "..."} every interval seconds. On pending, keep waiting. On approved, store data.key privately as SLEEK_API_KEY on that first read: the key is handed over once. On expired or 404 NOT_FOUND, start a new flow. See Device: Poll for the response contract.

Fallback: send the user to https://sleek.design/agents/setup, which handles sign-in, plan upgrade, and key creation in one place, and ask them to paste the key back to you. Keys can also be managed at https://sleek.design/dashboard/api-keys. The full key value is shown only once at creation, and a free account holds one active key at a time.

Plans: free accounts can try the API with their one-time trial credits (about one design run), so a new user can see their first design before any payment decision. Sustained use requires the Pro plan or higher. This file carries no figures on purpose — read the current price, billing periods and credit allowance from https://sleek.design/agents.md, which is generated from Sleek's live pricing, and quote them from there. When cost becomes relevant (the user asks, an upgrade is needed to continue, or you're about to send them to a payment page), state that pricing plainly, including the yearly option, so the user sees a payment step coming before they reach it.

Quick Reference: All Endpoints

Every endpoint the API exposes:

Create a key holding only the scopes the task uses.

Every row above is specified in full — request body, response shape, field defaults, status codes — in endpoints.md. This table is enough to pick an endpoint; read the reference when you need a contract detail it doesn't carry.

Error Shapes

{
  "defined": true,
  "code": "FORBIDDEN",
  "status": 403,
  "message": "...",
  "data": { "url": "https://sleek.design/..." }
}

401, 403 and 429 bodies may include data.url: a page where the user can fix the condition (create a key, upgrade the plan). Share it as-is.

Chat run-level errors (inside data.error):

For out_of_credits, relay error.url and wait for the user to resolve it. Follow Safe retries for replay versus a new attempt after either recoverable failure.