Kismet Fixtures
View .mdKismet Fixtures are production React experiences for search, property detail, content, reviews, and booking. A single component contract can ship to WordPress blocks and shortcodes, JavaScript embeds, and npm applications without duplicating the booking behavior underneath it.
The Developer API exposes the real fixture registry: 27 versioned manifests generated from the shipped component contracts. Each manifest tells a developer or coding agent what the fixture renders, which API operations supply its data, which settings remain editable in Kismet, and which install targets it supports.
Discover fixtures with the SDK
Section titled “Discover fixtures with the SDK”import { createKismetClient } from '@kismet-tech/sdk/server';
const kismet = createKismetClient({ apiKey: process.env.KISMET_DEVELOPER_API_KEY!, collection: 'sand-sea-condos', baseUrl: 'https://api.ksmt.app/v1',});
const registry = await kismet.fixture.list();
for (const fixture of registry.data) { console.log(fixture.id, fixture.status, fixture.installMethods);}Use the status filter when an agent should only select fixtures whose data contract is complete:
const ready = await kismet.fixture.list({ status: 'supported' });const propertyCard = await kismet.fixture.get('property-card');See listFixtures and getFixture for the HTTP contract.
What the registry contains
Section titled “What the registry contains”The current catalog spans the guest-facing system rather than a set of demo cards:
- search and discovery: results page, search results, map view, filters, property cards, and property sheets;
- property experience: property detail, gallery, header, footer, page shell, and booking CTA;
- content and trust: blog index/detail/cards, reviews, collection pages, and group pages;
- commerce: calendars, checkout, booking confirmation, and rates surfaces.
Every returned manifest includes:
| Field | What a builder can rely on |
|---|---|
id and fixtureVersion |
Stable identity and the component-contract version |
status and statusReason |
Whether the current Developer API fully supplies the fixture |
installMethods |
Supported targets such as npm, block, shortcode, or embed |
data[] |
Required operation, capability, coverage, and any declared gap |
settings |
Typed dashboard-editable configuration and defaults |
themeTokens |
Supported visual tokens without rewriting component internals |
enablement |
The collection-level control that turns the fixture on |
Built to survive customization
Section titled “Built to survive customization”Fixtures are not generated markup. Their source contracts, hydration behavior, route ownership, and cross-component communication are protected by TypeScript tests and structural ast-grep rules. This is what lets a developer or coding agent compose them while preserving Kismet’s data bindings, analytics, booking safeguards, and dashboard controls.
The manifest is the source of truth. Check data[].coverage before choosing a fixture, and never infer that an unsupported commercial action exists simply because the visual component exists.