BlinkHost capabilities used by Idam
Read supported application types, available operations and current workspace facts from the capability catalogue.
Last updated 2026-10-02
What you'll achieve
- Choose a supported application shape.
- Read current capabilities and workspace entitlements.
- Understand which integrations require separate setup.
Catalogue version: 1.2.0. The authenticated GET /api/idam/knowledge/
endpoint returns the catalogue, its SHA-256 digest, enabled configuration and
current workspace observations. Send X-Organization-Id using the normal
authenticated session. Query parameters are not accepted. The response is
private and must not be cached. Reading it does not create a project, allocate
credits or call an AI model.
Supported application shape
BlinkHost builds static frontend artifacts using native build dependencies. Customer backend execution uses WASM. A frontend build can use Node.js tools without deploying a Node.js server. Framework features that require a native Node.js or Python server need a supported alternative before release.
The supported starters are HTML, React with Vite, Vue with Vite, Svelte with Vite, Solid with Vite, and Astro static output. Idam and the IDE use the same versioned starter source. A starter does not establish that authentication, payments or another backend integration is already configured.
Capabilities and availability
Catalogue version 1.2.0 describes saved workspace and project conversations,
automatic project setup, source inspection and changes, private builds and previews,
attachments, sampled video frames, editable voice transcription, internet research,
MCP connections, the shared browser, application checks, repair, WASM module
setup and publication. Each entry links to its API route. Configuration reports whether the capability is
enabled for the deployment. health: "not_checked" means the endpoint has not
verified its workers or providers. Check the actual task and verification
results before describing a build, preview or release as successful.
Automatic project setup requires an implementation request and current workspace capacity. Questions and plans do not grant write authority. Source changes, resource creation and publication separately enforce the applicable membership, entitlements, source revision, funding and customer authorization.
The operations catalogue distinguishes tools offered to a model from workflows
and customer API actions. API templates identify the required project, task,
review or session. A catalogue entry does not add a tool to a model round.
| Operation | How it runs | Required scope |
|---|---|---|
project.create |
Automatic project workflow | Implementation request and workspace capacity |
project.read_source |
Native model tool | Current, screened source at the task revision |
idam.specialist_review, idam.specialist_report |
Optional focused expert turn | Project build, design or diagnosis; read-only and within the original task limit |
workspace.apply, workspace.build_private |
Automatic execution workflow | Original build authority or the applicable source review |
web.search, web.fetch |
Native model tools | Funded public query; fetch uses a cited search result |
mcp.connect, mcp.discovered_tools |
Customer connection flow, then permitted discovered tools | Current administrator grant and task scope |
preview.open, browser.start, browser.command |
Customer APIs | Private artifact access and current session ownership |
preview.verify, application.repair |
Automatic execution workflow | Recorded scenarios and bounded original build authority |
workspace.module.scaffold, workspace.module.build |
Customer review APIs | Exact approved module operation and compiler availability |
release.prepare, release.publish |
Customer release flow | Current verified preview and exact publication approval |
Research uses supplied public queries and returned search results. It does not send private project context to search or fetch arbitrary URLs. MCP contracts and results remain untrusted data. The shared browser runs verified static previews in isolation; it does not provide third-party sign-in or live external services. A passed preview check establishes only its recorded scenarios.
The manual_setup section identifies database creation and binding, custom domains,
production secret installation, payment account activation and third-party sign-in.
These use their platform or provider setup flows. Generated source alone does not
complete them, and the catalogue does not claim native automatic Idam operations
for them. A backend module starter is likewise not a deployed backend.
Idam selects a specialist only for a material security, accessibility, reliability or design concern. The specialist shares the task's bounded evidence and returns advice to Idam; it cannot edit, call other tools, delegate or publish. At most one review is available per task. Each model round uses the existing credit reservation and receipt accounting. A review is not proof that an application check ran.
Account facts
The endpoint reads the effective subscription entitlements, including applicable
contracts, add-ons and workspace overrides. It reports project and active
project limits, concurrent builds and previews, seats, storage, backend modules,
databases, monthly AI credits, custom domains and managed database availability.
An integer limit of -1 means unlimited for that entitlement.
Each observation has a source, observed_at, fresh_until, and one of:
| Status | Meaning |
|---|---|
known |
The source was read successfully; value includes its result, including an actual zero or false. |
absent |
No matching record exists, such as a wallet that has not been created. |
unavailable |
The source could not be read or validated. No value is inferred. |
Observations expire after five minutes and can have different observation times. Refresh expired facts before presenting them as current. Entitlement failures do not turn into Free-plan limits or a fabricated zero. The endpoint does not reuse cached subscription relations to answer current entitlement questions.
Available AI credits exclude existing reservations and expired unreserved funding
lots. Credits are pooled in the workspace. A balance does not measure monthly
consumption; monthly_consumption: "not_measured" makes that distinction
explicit. Unlisted resource usage is not measured by this endpoint.
The subscription summary includes its current status and period end. A permanent administrative sponsorship is reported only when the current subscription and plan match the grant evidence and there is no payment or renewal authority. An empty period end by itself does not establish sponsorship.
Evidence and privacy
New project tasks capture bounded platform evidence before their model input is quoted and credits are reserved. It includes catalogue version and digest, runtime constraints, configuration, effective limits and measured balances. The worker can cite its evidence ID. An exact retry returns the original task and evidence without creating another charge or silently changing its context. Historical task evidence describes the time it was captured, not the current account state.
The model-visible facts exclude editable plan names, payment identifiers, credentials and billing contact details. Workspace membership and active account status are checked from current records. Staff status alone does not permit reading another workspace. The evidence describes facts; it grants no permission to act and is not an application health certificate.
See the Idam developer guide for task, attachment and conversation APIs.
Help improve this page
Sign in to send page-specific feedback. For account-specific help, email support@blinkhost.me.